-= B E G I N =- X-EUFORUM: 20270 Date: 2008 May 1 3:17 From: Jason Gade Subject: Re: Namespace clobbering internals Shawn Pringle wrote: > > I saw the idea of keeping symbols out of the global scope necessary for > porting existing EUPHORIA applications and libraries to the new standard library. > Imagine you have 12,000 lines of code and you wish to use this new standard > > library. Can you imagine having to do a search and replace for every builtin > > to include an eu: namespace qualifier? > > Perhaps it is just better to avoid the names of builtins in the first place > unless > you really want to override them. Instead of open and close, the same kind > of > thing could be called connect() and disconnect(). > > Shawn Pringle But you wouldn't have to do that really (although automation certainly eases the task). You would only have to add a namespace qualifier to symbols that clashed. And if a namespace keyword was adopted as has been suggested then I think that conflicts would be far easier to fix. -- A complex system that works is invariably found to have evolved from a simple system that works. --John Gall's 15th law of Systemantics. "Premature optimization is the root of all evil in programming." --C.A.R. Hoare j. -= B E G I N =- X-EUFORUM: 20271 Date: 2008 May 1 3:19 From: Kat Subject: eunet mods I am adding an outgoing header hander to eunet. I may not finish tonite, but i am close to it now. It has some generic defaults, a way to modify them, and of course you can list them. It builds from the record to the http format and sends them. Kat -= B E G I N =- X-EUFORUM: 20272 Date: 2008 May 1 3:52 From: Shawn Pringle Subject: Re: Enhanced dir() function Marco Achury wrote: > > > Linux users currently only get info about 'd' attrib, > they would like to get a unix style chmod sequence like: > > "drwxr-x---" > > In this case the position of the char changes the sense. The character 'r' is documented as readonly in the dir() documentation. It would be trivial to give 'r' to the Linux community by testing if the current process has write access. It leads to cleaner looking code for dir() to provide the same interface regardless of platform. On the other hand, if you name your function to something new like folder_list(), then you can design any interface you like and you can set positional flags that are peclular to all the filesystems you will likely use: ext2, vfat, ntfs, and reiser. Shawn Pringle -= B E G I N =- X-EUFORUM: 20273 Date: 2008 May 1 3:54 From: Jeremy Cowgar Subject: Re: Namespace clobbering internals Jason Gade wrote: > > Shawn Pringle wrote: > > > > I saw the idea of keeping symbols out of the global scope necessary for > > porting existing EUPHORIA applications and libraries to the new standard library. > > Imagine you have 12,000 lines of code and you wish to use this new standard > > > > library. Can you imagine having to do a search and replace for every builtin > > > > to include an eu: namespace qualifier? > > > > But you wouldn't have to do that really (although automation certainly eases > the task). You would only have to add a namespace qualifier to symbols that > clashed. > I think Shawn is right. Say, you have your program that uses the function close() many times to close a file. Then you include, say, my pgsql.e file which also defines close(). Now, everywhere in his code that contains close() (as referring to the built-in close()), would require a prefix of eu: added. Otherwise, it would call the close() defined in pgsql.e, even though pgsql.e included inside of a namespace. I think I am back to my original thoughts on this: http://www.openeuphoria.org/EUforum/m20234.html Now, Matt replied that it would break existing code, as people who have over-ridden built-in's intentionally to have their own version of printf() for use while debugging or something. Depending on how many people do that, it may just be better to realize that as soon as anyone anywhere defines a function by the name of an internal, then you've lost the ability to use that internal (as soon as you include that file in your code that is). That doesn't seem quite right, but that is how things are looking right now? -- Jeremy Cowgar http://jeremy.cowgar.com -= B E G I N =- X-EUFORUM: 20274 Date: 2008 May 1 4:04 From: Shawn Pringle Subject: Re: Namespace clobbering internals Jeremy Cowgar wrote: > > Jason Gade wrote: > > > > Shawn Pringle wrote: > > > > > > I saw the idea of keeping symbols out of the global scope necessary for > > > porting existing EUPHORIA applications and libraries to the new standard library. > > > Imagine you have 12,000 lines of code and you wish to use this new standard > > > > > > library. Can you imagine having to do a search and replace for every builtin > > > > > > to include an eu: namespace qualifier? > > > > > > > But you wouldn't have to do that really (although automation certainly eases > > the task). You would only have to add a namespace qualifier to symbols that > > clashed. > > > > I think Shawn is right. Say, you have your program that uses the function close() > many times to close a file. Then you include, say, my pgsql.e file which also > defines close(). > > Now, everywhere in his code that contains close() (as referring to the built-in > close()), would require a prefix of eu: added. Otherwise, it would call the > close() defined in pgsql.e, even though pgsql.e included inside of a namespace. > > I think I am back to my original thoughts on this: > > http://www.openeuphoria.org/EUforum/m20234.html > > Now, Matt replied that it would break existing code, as people who have over-ridden > built-in's intentionally to have their own version of printf() for use while > debugging or something. > > Depending on how many people do that, it may just be better to realize that > as soon as anyone anywhere defines a function by the name of an internal, then > you've lost the ability to use that internal (as soon as you include that file > in your code that is). That doesn't seem quite right, but that is how things > are looking right now? > > -- > Jeremy Cowgar > http://jeremy.cowgar.com Consider this: (eu.e:) global procedure old_close( integer fd ) close( fd ) end procedure global procedure close( integer fd ) close( fd ) end procedure global function open( sequence filename, sequence access ) open( filename, access ) end function ---- main.ex include eu.e as eu include db.e as db integer fd object line fd = eu:open( "c:\autoexec.bat", "r" ) line = gets(fd) while sequence(line) ? line line = gets(fd) end while old_close( fd ) You see you can setup a builtin namespace without touching the backend source. You can still access the builtin but you have to alter how you access it. This would break any large project: win32lib.ew, ide.exw and thus inhibit the standard library's acceptance to large existing projects. This is what we did for redefining printf(). Often the new printf would need to call the old printf you needed to give the old printf another name: old_printf. Shawn -= B E G I N =- X-EUFORUM: 20275 Date: 2008 May 1 4:58 From: Kat Subject: Re: eunet mods I have mod'd my copy of eunet to get this url, http://en.wikipedia.org/wiki/USNS_General_Harry_Taylor_(T-AP-145) and http://en.wikipedia.org/wiki/USNS%5FGeneral%5FHarry%5FTaylor%5F%28T%2DAP%2D145%29 which eunet could not do this morning. I added several functions, using overly long names: sequence sendheader = {} -- as opposed to receiveheader defaultsetsendheader = set a default header setsendheaderline = sets a header line you ask for by name getsendheaderline = returns a header line you ask for by name formatsendheader = makes the header record presentable to eunet_send() urlencoding = not done yet -- convert non-alphanumeric to %hexhex pagedeflate = not done yet, un-gzip(?) -- any takers? I didn't do POST yet, gnite! All subject to change by Michael Sabal, if he's here? How to get this file out to you, i don't know yet. Kat -= B E G I N =- X-EUFORUM: 20276 Date: 2008 May 1 10:58 From: Matt Lewis Subject: Re: Namespace clobbering internals Jeremy Cowgar wrote: > > Jason Gade wrote: > > > > Shawn Pringle wrote: > > > > > > I saw the idea of keeping symbols out of the global scope necessary for > > > porting existing EUPHORIA applications and libraries to the new > > > standard library. Imagine you have 12,000 lines of code and you wish > > > to use this new standard library. Can you imagine having to do a > > > search and replace for every builtin to include an eu: namespace > > > qualifier? > > > > But you wouldn't have to do that really (although automation certainly > > eases the task). You would only have to add a namespace qualifier to > > symbols that clashed. > > > > I think Shawn is right. Say, you have your program that uses the function > close() many times to close a file. Then you include, say, my pgsql.e file > which also defines close(). > > Now, everywhere in his code that contains close() (as referring to the > built-in close()), would require a prefix of eu: added. Otherwise, it > would call the close() defined in pgsql.e, even though pgsql.e included > inside of a namespace. Well, remember, this is only if he wants to do add something new to his existing 12KLOC. If he keeps using the libraries he has, nothing changes. How many built-ins are we talking about overriding? > I think I am back to my original thoughts on this: > > http://www.openeuphoria.org/EUforum/m20234.html > > Now, Matt replied that it would break existing code, as people who have > over-ridden built-in's intentionally to have their own version of printf() > for use while debugging or something. Yes. But also consider your hypothetical pgsql.e. It couldn't use its own close() function, unless it defines a namespace for itself. This fails the principle of least surprise. > Depending on how many people do that, it may just be better to realize > that as soon as anyone anywhere defines a function by the name of an > internal, then you've lost the ability to use that internal (as soon as > you include that file in your code that is). That doesn't seem quite right, > but that is how things are looking right now? I remain unconvinced that refactoring your code to accommodate a new library is too much of a burden. Matt -= B E G I N =- X-EUFORUM: 20277 Date: 2008 May 1 11:46 From: ChrisBurch3 Subject: Forward referencing Hi How much of a problem would it be to re introduce the bug that Rob squashed a few years ago for eu 4 - ie calling functions and procedures after they have been called? routine _id would still be unaffected, so no present code would be broken. It may make includes a bit easier to implement. Chris -= B E G I N =- X-EUFORUM: 20278 Date: 2008 May 1 12:48 From: Michael J. Sabal Subject: Re: eunet mods Kat wrote: > > I have mod'd my copy of eunet to get this url, > > All subject to change by Michael Sabal, if he's here? How to get this file out > to you, i don't know yet. > > Kat Wow, that's awesome! It probably would have taken me a couple weeks to get everything done and tested, squeezing it in between the work I get paid for :). If you have, or were able to sign up for a SourceForge account, and had SVN installed, I could add you to the project so you could commit code directly. Otherwise, you could email me your modded version, or submit the modded .e to recent user contributions. My addy is m underscore sabal ta yahoo tod com. Thanks. Michael Sabal -= B E G I N =- X-EUFORUM: 20279 Date: 2008 May 1 13:44 From: Jeremy Cowgar Subject: Re: Namespace clobbering internals Matt Lewis wrote: > > How many built-ins are we talking about overriding? > Here are some common ones that would make libraries easier if we can override them. The reason I say this, is why come up with 20 creative names for the same task just to prevent collisions. Now, if I want to delete a record from a database I have to use delete, then to remove something from a map, I have to use vanish, then to delete an item in a sequence I have to remove, etc... If diff libs could all use remove or delete to remove or delete something, then it makes things easier. append, prepend, remove, length, compare, equal, find, match, sort, open, close. That's just real quick off the top of my head. Again, being able to use these function names makes programming libraries and using libraries simpler. map:length() for instance. Instead of coming up with map:size(), map:length_of(), map:mass(), map:volume(), map:extent(), map:porpotion(), etc... or... map:remove() instead of map:delete(), map:take(), map:take_off(), map:withdraw(), etc... Again, this creates a simpler API. One problem with programming in Forth is the requirement of every single word has to be a new name, so when programming anything sizeable in forth you wind up becoming an English scholar and your dictionary becomes your greatest tool in programming. You then come up with names that are so very similar that later you even question what it does. > > Yes. But also consider your hypothetical pgsql.e. It couldn't use its > own close() function, unless it defines a namespace for itself. This > fails the principle of least surprise. > Yes, that's a problem. I wonder if in addition to a eu: namespace if we should borrow a good idea from the OO people (not to make Euphoria OO, and not to suggest that I like Java better than Euphoria, but why not learn from other languages? To not learn from other languages is not very smart), self:, this:, current:, me: or something like that. Just more thinking about the subject. Matt, I think the eu: namespace is a critical addition, even if we do or do not use it to solve some of these problems we are speaking of right now. What it will do is give, in example, the pgsql.e file the ability to call the built-in close() or it's own close(). I do not think anyone will complain if we add the eu: namespace as it will not break a thing and will only help in situations. Can you give me a pointer or direction in implementing this? -- Jeremy Cowgar http://jeremy.cowgar.com -= B E G I N =- X-EUFORUM: 20280 Date: 2008 May 1 13:48 From: C Bouzy Subject: Win32Lib Error Fixes Hello All, Today I began using the latest Win32Lib for Nexus Radio and I found two errors. Look for the procedure setScrollRange and find: ctrl_Range[ id ][1] = { min, max } Replace it with: ctrl_Range[ id ][1] = { min, max } ctrl_Range[ id ][2] = { min, max } Also replace the DefProcessing function with the follow code: ----------------------------------------------------------------------------- function DefProcessing(integer id, integer pSource, atom hWnd, atom iMsg, atom wParam, atom lParam) ----------------------------------------------------------------------------- atom lResult lResult = 0 if (id = 0) or (pSource = kMainMsg) then lResult = w32Func( xDefWindowProc, { hWnd, iMsg, wParam, lParam } ) else lResult = w32Func( xCallWindowProc, { ctrl_Function[id], hWnd, iMsg, wParam, lParam } ) end if if lResult = 0 then return 0 else return lResult end if end function r_defaultProcessing = routine_id("DefProcessing") ~ CBouzy "If you do what you have always done, you will get what you always got." -= B E G I N =- X-EUFORUM: 20281 Date: 2008 May 1 14:49 From: CChris Subject: Re: Namespace clobbering internals Jeremy Cowgar wrote: > > Jason Gade wrote: > > > > Shawn Pringle wrote: > > > > > > I saw the idea of keeping symbols out of the global scope necessary for > > > porting existing EUPHORIA applications and libraries to the new standard library. > > > Imagine you have 12,000 lines of code and you wish to use this new standard > > > > > > library. Can you imagine having to do a search and replace for every builtin > > > > > > to include an eu: namespace qualifier? > > > > > > > But you wouldn't have to do that really (although automation certainly eases > > the task). You would only have to add a namespace qualifier to symbols that > > clashed. > > > > I think Shawn is right. Say, you have your program that uses the function close() > many times to close a file. Then you include, say, my pgsql.e file which also > defines close(). > > Now, everywhere in his code that contains close() (as referring to the built-in > close()), would require a prefix of eu: added. Otherwise, it would call the > close() defined in pgsql.e, even though pgsql.e included inside of a namespace. > > I think I am back to my original thoughts on this: > > http://www.openeuphoria.org/EUforum/m20234.html > > Now, Matt replied that it would break existing code, as people who have over-ridden > built-in's intentionally to have their own version of printf() for use while > debugging or something. > > Depending on how many people do that, it may just be better to realize that > as soon as anyone anywhere defines a function by the name of an internal, then > you've lost the ability to use that internal (as soon as you include that file > in your code that is). That doesn't seem quite right, but that is how things > are looking right now? > > -- > Jeremy Cowgar > http://jeremy.cowgar.com If someone somewhere overrides a builtin, I guess that the purpose is to extend the builtin without changing its normal processing. This way, the user can take advantage of the enhancements without bothering to use yet another name[space]. Then, what is the point of insisting on calling the builtin? For the sake of peace of mind, something easy can be done. Usually, extending a builtin takes the following form: procedure print_wrapped(whatever) -- wrap builtin as a regular routine, because builtins have no routine_id print(whatever) end procedure -- now we have an alternate way of calling print() constant print_id=routine_id("print_wrapped") -- now redefine the builtin, while elying on it if the extensions are not -- needed on some call. global procedure print(whatever) -- Very, very unfortunately, the signature cannot be changed. if my_own_procesing() then my_smecial_code() else call_proc(print_id,{whatever}) end if end procedure Extending a builtin otherwise would have to be discouraged. Notice that, if print_id is made global, then you can call the vintage print() again. Some piece of (good) kludgy ol' Eu. In most languages, the proecess is very straightforward. CChris -= B E G I N =- X-EUFORUM: 20282 Date: 2008 May 1 14:53 From: Greg Haberek Subject: Re: Forward referencing ChrisBurch3 wrote: > > Hi > > How much of a problem would it be to re introduce the bug that Rob squashed > a > few years ago for eu 4 - ie calling functions and procedures after they > have been called? routine _id would still be unaffected, so no present code > would be broken. It may make includes a bit easier to implement. > > Chris I don't see the necessity for this. It opens up all sorts of potential bugs. This would be the proper method of forward referencing (which I use frequently). integer r_Func2 function Func1( integer i ) return call_func( r_Func2, {2} ) end function function Func2( integer i ) return i * 2 end function r_Func2 = routine_id("Func2") Could you post an example of how you could better implement the includes with the bug reintrocuced? -Greg -= B E G I N =- X-EUFORUM: 20283 Date: 2008 May 1 14:58 From: Jeremy Cowgar Subject: Re: Namespace clobbering internals CChris wrote: > > If someone somewhere overrides a builtin, I guess that the purpose is to extend > the builtin without changing its normal processing. This is not the case, Please see my post: http://www.openeuphoria.org/EUforum/m20279.html -- Jeremy Cowgar http://jeremy.cowgar.com -= B E G I N =- X-EUFORUM: 20284 Date: 2008 May 1 15:15 From: Jason Gade Subject: Re: Namespace clobbering internals Jeremy Cowgar wrote: > > CChris wrote: > > > > If someone somewhere overrides a builtin, I guess that the purpose is to extend > > the builtin without changing its normal processing. > > This is not the case, Please see my post: > > http://www.openeuphoria.org/EUforum/m20279.html > > -- > Jeremy Cowgar > http://jeremy.cowgar.com What you describe isn't overriding, it's overloading. The namespace proposals so far (default namespace in include, eu namespace for builtins) should enable overloading. Unless I'm missing something in the conversation. -- A complex system that works is invariably found to have evolved from a simple system that works. --John Gall's 15th law of Systemantics. "Premature optimization is the root of all evil in programming." --C.A.R. Hoare j. -= B E G I N =- X-EUFORUM: 20285 Date: 2008 May 1 15:36 From: Jeremy Cowgar Subject: Re: Namespace clobbering internals Jason Gade wrote: > > > What you describe isn't overriding, it's overloading. > Yes, but the original problem is that there is no way to overload, it is overriding. > The namespace proposals so far (default namespace in include, eu namespace for > builtins) should enable overloading. Except that it will force people to use eu: in their code even when they include map.e as map ... Let's say map overload's the find() function (may be a dumb example, but an example). include map.e as map map:map m m = map:new() m = map:put(m, "name", "Jason") m = map:find(m, "Jason") sequence e e = {1,2,3} ? find(3, e) So, the lower part dealing with the sequence was code that existed already in programmer Joe's code. Now Joe makes use of the new map. Well, his find() for the sequence e is now broke. He has to go back and prefix find() with eu: Now, as Matt said, it may not be that big of a conversion path for people to do that. My original thinking was in the above example, find() exists in both the built-in namespace and the map namespace. If there is a conflict and no namespace is given, then Euphoria should chose the built-in function, however, that would take away the ability to override a built-in (again as Matt pointed out to me). -- Jeremy Cowgar http://jeremy.cowgar.com -= B E G I N =- X-EUFORUM: 20286 Date: 2008 May 1 15:43 From: CChris Subject: Re: Win32Lib Error Fixes C Bouzy wrote: > > Hello All, > > Today I began using the latest Win32Lib for Nexus Radio and I found two errors. > > > Look for the procedure setScrollRange and find: > > ctrl_Range[ id ][1] = { min, max } > > > Replace it with: > > ctrl_Range[ id ][1] = { min, max } > ctrl_Range[ id ][2] = { min, max } > > Are you sure? First, there are several instances of the statment in the routine. Which one is supposed to be completed? Second, ctrl_Range[id] holds either: * for Window controls, a pair of ranges, for H and V scroll bars; * For other usable controls, a single range, they have only one to monitor. I checked further, and I think the error is in getScrollRange rather, which should read as global function getScrollRange( object id ) -- Get the allowable range for a scroll bar atom lWhichBar if sequence(id) then lWhichBar = w32iff(find(id[2], {SB_VERT,SB_HORZ}), id[2], SB_VERT) id = id[1] else lWhichBar = SB_VERT end if -- changed part if ctrl_Family[id]=WINDOW then if lWhichBar = SB_HORZ then return ctrl_Range[id][2] else return ctrl_Range[id][1] end if else return ctrl_Range[id][1] end if end function See if this isn't a better fix, I expect it is. > Also replace the DefProcessing function with the follow code: > > > ----------------------------------------------------------------------------- > function DefProcessing(integer id, integer pSource, atom hWnd, atom iMsg, atom wParam, atom > lParam) > ----------------------------------------------------------------------------- > atom lResult > lResult = 0 > > if (id = 0) or (pSource = kMainMsg) then > lResult = w32Func( xDefWindowProc, { hWnd, iMsg, wParam, lParam } ) > else > lResult = w32Func( xCallWindowProc, { ctrl_Function[id], hWnd, iMsg, wParam, > lParam } ) > end if > > if lResult = 0 > then > return 0 > else > return lResult > end if > end function > r_defaultProcessing = routine_id("DefProcessing") > > The second chunk of code looks like an uselessly complex way to return lResult. Does it make a difference? I added the lResult=0 initialisation. CChris > ~ CBouzy > > "If you do what you have always done, you will get what you always got." -= B E G I N =- X-EUFORUM: 20287 Date: 2008 May 1 15:51 From: CChris Subject: Re: Namespace clobbering internals Jeremy Cowgar wrote: > > CChris wrote: > > > > If someone somewhere overrides a builtin, I guess that the purpose is to extend > > the builtin without changing its normal processing. > > This is not the case, Please see my post: > > http://www.openeuphoria.org/EUforum/m20279.html > > -- > Jeremy Cowgar > http://jeremy.cowgar.com I see. The overloading of a single routine name to perform similar actions on different sorts of objects has been consistently fought off on this list. Of course, as a user of some OO languages (mostly Eiffel and less Delphi), I think that overloading would make the language much easier to learn and use. I'd be delighted if we could at last come back from this nonsense of "if it does something else, give it another name". Nevertheless, extensions in the way I described are also useful, and should be made posible *as well*. CChris -= B E G I N =- X-EUFORUM: 20288 Date: 2008 May 1 15:53 From: ChrisBurch2 Subject: Re: Forward referencing Greg Haberek wrote: > > ChrisBurch3 wrote: > > > > Hi > > > > How much of a problem would it be to re introduce the bug that Rob squashed > > a > > few years ago for eu 4 - ie calling functions and procedures after they > > have been called? routine _id would still be unaffected, so no present code > > would be broken. It may make includes a bit easier to implement. > > > > Chris > > I don't see the necessity for this. It opens up all sorts of potential bugs. > This would be the proper method of forward referencing (which I use frequently). > Well, it didn't for 2-3 weeks until the 'bug' was noticed. > > integer r_Func2 > > function Func1( integer i ) > return call_func( r_Func2, {2} ) > end function > > function Func2( integer i ) > return i * 2 > end function > r_Func2 = routine_id("Func2") > > > Well, that may the 'proper' way of doing things, but function Func1( integer i ) atom x Func2(2) end function function Func2( integer i ) return i * 2 end function is a lot easier. I guess C must have it wrong then. > Could you post an example of how you could better implement the includes with > the bug reintrocuced? > > -Greg Weeeeeell, thats a bit more tricky, and probably more to do with lazy programming than anything else a.e contains stuff b.e contains other stuff main.exw include a.e include b.e contains funcs called in both a and e later on b.e is edited to add a great function then a.e is edited to call the great function in b.e - but it can't, because its not in the right order. So you create routine ids, which is fine, but its taken extra work to do it. So, perhaps you could give an example of an introduced bug created by forward referencing. Chris -= B E G I N =- X-EUFORUM: 20289 Date: 2008 May 1 15:53 From: CChris Subject: Re: Namespace clobbering internals Jason Gade wrote: > > Jeremy Cowgar wrote: > > > > CChris wrote: > > > > > > If someone somewhere overrides a builtin, I guess that the purpose is to extend > > > the builtin without changing its normal processing. > > > > This is not the case, Please see my post: > > > > http://www.openeuphoria.org/EUforum/m20279.html > > > > -- > > Jeremy Cowgar > > http://jeremy.cowgar.com > > What you describe isn't overriding, it's overloading. > > The namespace proposals so far (default namespace in include, eu namespace for > builtins) should enable overloading. > > Unless I'm missing something in the conversation. > > -- > A complex system that works is invariably found to have evolved from a simple > system that works. > --John Gall's 15th law of Systemantics. > > "Premature optimization is the root of all evil in programming." > --C.A.R. Hoare > > j. Yes, they would. CChris -= B E G I N =- X-EUFORUM: 20290 Date: 2008 May 1 16:01 From: Jason Gade Subject: Re: Forward referencing I believe that the bug referenced only applied to routine_id() calls, not forward referencing in general. Enabling code like this: function Func1( integer i ) return call_func( routine_id("Func2"), {2} ) -- "Func2" not resolved until called end function function Func2( integer i ) return i * 2 end function I support this bug/feature for routine_id, not for general forward referencing. I've heard that it would have helped writing Win32lib greatly. -- A complex system that works is invariably found to have evolved from a simple system that works. --John Gall's 15th law of Systemantics. "Premature optimization is the root of all evil in programming." --C.A.R. Hoare j. -= B E G I N =- X-EUFORUM: 20291 Date: 2008 May 1 16:01 From: Jason Gade Subject: Re: Namespace clobbering internals Jeremy Cowgar wrote: > > Jason Gade wrote: > > > > > > What you describe isn't overriding, it's overloading. > > > > Yes, but the original problem is that there is no way to overload, it is overriding. > > > The namespace proposals so far (default namespace in include, eu namespace for > > builtins) should enable overloading. > > Except that it will force people to use eu: in their code even when they include > map.e as map ... Let's say map overload's the find() function (may be a dumb > example, but an example). > > > include map.e as map > > map:map m > m = map:new() > m = map:put(m, "name", "Jason") > m = map:find(m, "Jason") > > sequence e > e = {1,2,3} > ? find(3, e) > > > So, the lower part dealing with the sequence was code that existed already in > programmer Joe's code. Now Joe makes use of the new map. Well, his find() for > the sequence e is now broke. He has to go back and prefix find() with eu: > > Now, as Matt said, it may not be that big of a conversion path for people to > do that. My original thinking was in the above example, find() exists in both > the built-in namespace and the map namespace. If there is a conflict and no > namespace is given, then Euphoria should chose the built-in function, however, > that would take away the ability to override a built-in (again as Matt pointed > out to me). > > -- > Jeremy Cowgar > http://jeremy.cowgar.com I understand the problem a bit better now. A proper solution requires some thought I think... -- A complex system that works is invariably found to have evolved from a simple system that works. --John Gall's 15th law of Systemantics. "Premature optimization is the root of all evil in programming." --C.A.R. Hoare j. -= B E G I N =- X-EUFORUM: 20292 Date: 2008 May 1 16:19 From: ChrisBurch2 Subject: Re: Forward referencing Hi I've just a forum search for 'forward reference' Sorry, looks like a got hornets nest, and may be too much trouble to re write the interpreter. However, I'm still interested as to why allowing forward refs would introduce bugs. Is this not a simplistic view of how an eu progrom is interpreted. 1. stretch out all the files (includes etc) into one long program 2. build a table with all the variables (globals and locals) and functions and procedures. 3. run the program with the addresses of the functions referenced from the name table if so, why not allow references to funcs and procedures that occur later in the program list? Chris -= B E G I N =- X-EUFORUM: 20293 Date: 2008 May 1 18:09 From: Jeremy Cowgar Subject: 3.2, Wrapping DLLs and Float types I've wrapped PgSQL and used Sqlite, PCRE and Iup in 3.2 now w/no problems, once the stack offset was fixed for gcc 4.3.0, however, none of those use the Float type. Now, before going further, the C examples I have created work great, and the wrapper that I've created works identical to the C examples when executed with Euphoria 3.1.1. However, the results are different with the same wrapper, the same examples on the same computer when run with 3.2. I am now wrapping LibHaru, which will be released into the archives and will give Euphoria PDF capabilities. However, floats, I have identified what I think is a bug, but I do not have the knowledge to track it down. The bug is this: constant fHPDF_Page_SetFontAndSize = define_c_func(lib, "HPDF_Page_SetFontAndSize", {P, P, F}, I), fHPDF_Page_TextOut = define_c_func(lib, "HPDF_Page_TextOut", {P, F, F, P}, I) -- P = C_POINTER, F = C_FLOAT, I = C_INT. The parameters for TextOut are: Page, X, Y and Text. The problem is the resulting PDF outputs for X, Y: 761 0 Td when it should be 60 761. What that tells PDF readers is unimportant, the part that is important is that Y is being shifted to X's position, and Y is 0. The parameters for SetFontAndSize are: Page, Font, Size. The Font section is output correctly, but the size is in the PDF as: 0 Tf when it should be 12 Tf. So, once again the Float is being lost/corrupted somehow in 3.2. Again, this all works great in 3.1.1. Thanks for any input. -- Jeremy Cowgar http://jeremy.cowgar.com -= B E G I N =- X-EUFORUM: 20294 Date: 2008 May 1 18:15 From: Jeremy Cowgar Subject: Re: 3.2, Wrapping DLLs and Float types Oh, I should add, that is 3.2 is also compiled with gcc 4.3.0, so it may be another change in 4.3.0 ? -- Jeremy Cowgar http://jeremy.cowgar.com -= B E G I N =- X-EUFORUM: 20295 Date: 2008 May 1 18:40 From: Jason Gade Subject: Re: 3.2, Wrapping DLLs and Float types Jeremy Cowgar wrote: > > I've wrapped PgSQL and used Sqlite, PCRE and Iup in 3.2 now w/no problems, once > the stack offset was fixed for gcc 4.3.0, however, none of those use the Float > type. > > Now, before going further, the C examples I have created work great, and the > wrapper that I've created works identical to the C examples when executed with > Euphoria 3.1.1. However, the results are different with the same wrapper, the > same examples on the same computer when run with 3.2. > > I am now wrapping LibHaru, which will be released into the archives and will > give Euphoria PDF capabilities. However, floats, I have identified what I think > is a bug, but I do not have the knowledge to track it down. The bug is this: > > > constant > fHPDF_Page_SetFontAndSize = define_c_func(lib, "HPDF_Page_SetFontAndSize", > {P, P, F}, I), > fHPDF_Page_TextOut = define_c_func(lib, "HPDF_Page_TextOut", > {P, F, F, P}, I) > > -- P = C_POINTER, F = C_FLOAT, I = C_INT. > > > The parameters for TextOut are: Page, X, Y and Text. The problem is the resulting > PDF outputs for X, Y: 761 0 Td when it should be 60 761. What that tells PDF > readers is unimportant, the part that is important is that Y is being shifted > to X's position, and Y is 0. > > The parameters for SetFontAndSize are: Page, Font, Size. The Font section is > output correctly, but the size is in the PDF as: 0 Tf when it should be 12 Tf. > > So, once again the Float is being lost/corrupted somehow in 3.2. Again, this > all works great in 3.1.1. > > Thanks for any input. > > -- > Jeremy Cowgar > http://jeremy.cowgar.com This is getting outside of my expertise, but where there any compiler flags different for 3.0 than from 3.2? Maybe the offset you changed was still a little wrong but close enough to work most of the time? I'm wondering if one of the float arguments is being passed in a register instead of on the stack, or if it is being consumed by another function, or whether it is being passed at all. Also, are you sure the arguments are supposed to be floats and not doubles? I know they're different sizes but I don't know if GCC allocates the same amount of space on the stack for them. -- A complex system that works is invariably found to have evolved from a simple system that works. --John Gall's 15th law of Systemantics. "Premature optimization is the root of all evil in programming." --C.A.R. Hoare j. -= B E G I N =- X-EUFORUM: 20296 Date: 2008 May 1 18:50 From: Jeremy Cowgar Subject: Re: 3.2, Wrapping DLLs and Float types Jason Gade wrote: > > This is getting outside of my expertise, but where there any compiler flags > different for 3.0 than from 3.2? Maybe the offset you changed was still a little > wrong but close enough to work most of the time? > I'm not sure either. Matt helped me find the right offsets. > Also, are you sure the arguments are supposed to be floats and not doubles? Yes, I just went back and tripple checked. HPDF_STATUS HPDF_Page_SetFontAndSize (HPDF_Page page, HPDF_Font font, HPDF_REAL size); HPDF_STATUS HPDF_Page_TextOut (HPDF_Page page, HPDF_REAL xpos, HPDF_REAL ypos, const char *text); In hpdf_types.h: /* float type (32bit IEEE754) */ typedef float HPDF_REAL; -- Jeremy Cowgar http://jeremy.cowgar.com -= B E G I N =- X-EUFORUM: 20297 Date: 2008 May 1 20:44 From: C Bouzy Subject: Re: Win32Lib Error Fixes Hello CChris, I have been using Win32Lib since 2001 for all of my apps :) The error is in setScrollRange, just replace all 3 instances. In regards to DefProcessing, the code I posted might seem redundant but it is not. In some cases when running large complex Win32Lib apps on some machines you will get a weird error, that simple piece of code fixes it. ~ C Bouzy "If you do what you have always done, you will get what you always got." -= B E G I N =- X-EUFORUM: 20298 Date: 2008 May 1 21:27 From: CChris Subject: Re: Forward referencing Jason Gade wrote: > > I believe that the bug referenced only applied to routine_id() calls, not forward > referencing in general. > > Enabling code like this: > > > function Func1( integer i ) > return call_func( routine_id("Func2"), {2} ) -- "Func2" not resolved until called > end function > > function Func2( integer i ) > return i * 2 > end function > > > I support this bug/feature for routine_id, not for general forward referencing. > I've heard that it would have helped writing Win32lib greatly. > > -- > A complex system that works is invariably found to have evolved from a simple > system that works. > --John Gall's 15th law of Systemantics. > > "Premature optimization is the root of all evil in programming." > --C.A.R. Hoare > > j. In a project with hundreds of routines that may call one another in any order and are hopefully split across a few files, imagine how tricky it is to position routines so that they are seen by the includes that need them and appear after any routine thta calls them. You can do everything using routine_ids, but this accounted for a few dozens of undocumented global symbols in previous versions of win32lib. I could clean up that mess using the alternate w32routine_id, but: * routine placement is just doable, not easily so * any given large library has no need for a w32routine_id mechanism. Forward referencing is not a problem at all: see Orac and my modified interperter, for instance. Additionally, backward referencing forces to write program upside down: utilities first, then routines that call them, and on and on. I don't know about you, but I usually read from top to bottom. This makes programs needlessly harder to understand. CChris -= B E G I N =- X-EUFORUM: 20299 Date: 2008 May 1 21:33 From: CChris Subject: Re: Forward referencing ChrisBurch2 wrote: > > Hi > > I've just a forum search for 'forward reference' Sorry, looks like > a got hornets nest, and may be too much trouble to re write the interpreter. > > However, I'm still interested as to why allowing forward refs would > introduce bugs. > > Is this not a simplistic view of how an eu progrom is interpreted. > > 1. stretch out all the files (includes etc) into one long program > 2. build a table with all the variables (globals and locals) and functions > and procedures. > 3. run the program with the addresses of the functions referenced > from the name table > > if so, why not allow references to funcs and procedures that occur > later in the program list? > > Chris Probably because of he various checks to be performed on exiting a file and on completing parsing. That was the hardest part in implementing it. routine_id(unheard_of_routine) should return -1, no problem with that either. Perhaps it is the fright of and recoiling at... yes, spaghetti phantoms in the code. I've never seen such coding, but perhaps I'm just too young. CChris -= B E G I N =- X-EUFORUM: 20300 Date: 2008 May 1 21:43 From: Jason Gade Subject: Re: Forward referencing CChris wrote: > > Jason Gade wrote: > > > > I believe that the bug referenced only applied to routine_id() calls, not forward > > referencing in general. > > > > Enabling code like this: > > > > > > function Func1( integer i ) > > return call_func( routine_id("Func2"), {2} ) -- "Func2" not resolved until called > > end function > > > > function Func2( integer i ) > > return i * 2 > > end function > > > > > > I support this bug/feature for routine_id, not for general forward referencing. > > I've heard that it would have helped writing Win32lib greatly. > > > > -- > > A complex system that works is invariably found to have evolved from a simple > > system that works. > > --John Gall's 15th law of Systemantics. > > > > "Premature optimization is the root of all evil in programming." > > --C.A.R. Hoare > > > > j. > > In a project with hundreds of routines that may call one another in any order > and are hopefully split across a few files, imagine how tricky it is to position > routines so that they are seen by the includes that need them and appear after > any routine thta calls them. If the program is factored correctly then I disagree. > You can do everything using routine_ids, but this accounted for a few dozens > of undocumented global symbols in previous versions of win32lib. I could clean > up that mess using the alternate w32routine_id, but: > * routine placement is just doable, not easily so > * any given large library has no need for a w32routine_id mechanism. > > Forward referencing is not a problem at all: see Orac and my modified interperter, > for instance. > > Additionally, backward referencing forces to write program upside down: utilities > first, then routines that call them, and on and on. I don't know about you, > but I usually read from top to bottom. This makes programs needlessly harder > to understand. > > CChris Again, I disagree here too. Yes, I read from top to bottom usually, but I know that in most programming languages the object is to find the main routine (or the file containing the main routine) and start there. I don't remember the reasons now, but I remember Rob had pretty good reasons for not having general forward-referencing. I think that I'll stick with that. After all, he's the one with the degree, not me. -- A complex system that works is invariably found to have evolved from a simple system that works. --John Gall's 15th law of Systemantics. "Premature optimization is the root of all evil in programming." --C.A.R. Hoare j. -= B E G I N =- X-EUFORUM: 20301 Date: 2008 May 1 22:01 From: CChris Subject: Re: Win32Lib Error Fixes C Bouzy wrote: > > Hello CChris, > > I have been using Win32Lib since 2001 for all of my apps :) The error is in > setScrollRange, just replace all 3 instances. > We are, I think, both right. getScrollRange() checks whether the bar is horizontal or vertical, and returns item 1 or 2 in ctrl_Range[id] accordingly. Since a progressbar or somesuch may be either horizontal or vertical, both fields should be ranges, and your fix works. However, all controls have one range to take care of, except Window. So, leaving setScrollRange() alone and changing getScrollRange() should work just as well. I prefer the latter as more consistent. Could you tell me whether that way works for you? CChris > In regards to DefProcessing, the code I posted might seem redundant but it is > not. In some cases when running large complex Win32Lib apps on some machines > you will get a weird error, that simple piece of code fixes it. > Ok, but is the error simply lResult being uninitialised, or lResult holding something unexpected? Just curious here. CChris > ~ C Bouzy > > "If you do what you have always done, you will get what you always got." -= B E G I N =- X-EUFORUM: 20302 Date: 2008 May 1 22:15 From: c.k.lester Subject: Re: Forward referencing CChris wrote: > > In a project with hundreds of routines that may call one another in any order > and are hopefully split across a few files, imagine how tricky it is to position > routines so that they are seen by the includes that need them and appear after > any routine thta calls them. I can tell you it's a pain in the brain. BBCMF uses TONS of include files (modularization, dontcha know), and I have sometimes had to jostle them around, or move funcs/procs to a more appropriate location. Having said that, I don't need forward referencing. I like the define-it- before-you-use-it approach. It's intuitive to me, now. :/ -= B E G I N =- X-EUFORUM: 20303 Date: 2008 May 2 0:53 From: Jeremy Cowgar Subject: New Docs, new layout When adding many new functions and then trying to document those functions, then with the addition of new includes using namespaces, the current method of grouping the function reference by A-B, C-D, etc... became very difficult. I spoke to Rob and with his blessing, I've changed the way the documentation works a bit. I will update the doc processing before the release of 3.2/4.0 to include an alphabetical index of all functions, but that is not there yet. The new docs add's a navigation toolbar to the top and bottom of the library reference, and it also groups functions by their functional group, not by alphabetical order. So, on one page, you can view all the functions dealing with sequences. On another page, you can view all the functions dealing with the operating system, etc... The library page is still there that lists all the functions with a short description grouped by their functional type. I have compiled the new documentation and placed it on my web server for others to view and comment on. Here are a few key URL's you will want to visit: Starting point: http://jeremy.cowgar.com/euphoria/overview.htm Where things begin to change: http://jeremy.cowgar.com/euphoria/library.htm Where you can see a functional grouping page instead of an alphabetical grouping: http://jeremy.cowgar.com/euphoria/lib_math.htm This is a rough draft, so please let me know what you think. -- Jeremy Cowgar http://jeremy.cowgar.com -= B E G I N =- X-EUFORUM: 20304 Date: 2008 May 2 1:04 From: Jason Gade Subject: Re: New Docs, new layout With only a glance so far, I like it. Familiar, yet functional. I'll dig in a bit more. -- A complex system that works is invariably found to have evolved from a simple system that works. --John Gall's 15th law of Systemantics. "Premature optimization is the root of all evil in programming." --C.A.R. Hoare j. -= B E G I N =- X-EUFORUM: 20305 Date: 2008 May 2 2:35 From: Shawn Pringle Subject: Re: Namespace clobbering internals If you set builtins as always being the one used when a namespace is not specified you will break overloading. If you leave the interpreter the way it is, your new library's use of functions with the same names as builtins will break much more code than what's in print.e. A third alternative is to introduce some kind of hiding into a namespace. A fourth alternative involves avoiding any builtin names. When I say, hiding objects into a namespace. I would like you to suppose that insert() is a routine defined in db.e. 'include db.e' means you can only access db.e's insert() function as insert(). 'include db.e as db' means you can access db.e's insert() function as both insert() and db:insert(). You could hack the backend such that that allows you can get access to insert() as db:insert() but not as insert(). I don't like the idea of modifying the backend, though. The fourth alternative is, you can use the same method names over and over if you ensure they are not builtins. All new libraries can use routines names over and over so long as the name doesn't appear twice in the same file. So, you may need to find synonyms for some builtin names but you only need to find one synonym for each one. There is no modifying the backend and you wont break any existing code. The fourth alternative, I have to say is less bug proned than the third alternative since you are not modifying the interpreter C-source itself. You don't need to put the builtins into their own namespace because you purposely avoid using builtins. This means that large programs like Judith's IDE could use it without renaming or namespaceing other things. The third alternative has appeal to me. I think it would be neat to do a kind of overloading only for things inside a namespace. You might introduce bugs into the EU interpreter but large programs could then use this library without renaming or namespacing other things. The first two ideas are well understood by anyone who reads Matt's posts so I will not talk more about them here. :) Shawn -= B E G I N =- X-EUFORUM: 20306 Date: 2008 May 2 11:15 From: Shawn Pringle Subject: Re: New Docs, new layout Hey Jeremy, Two things: Firstly, I found two functions in the category 'C-Interface'; free_console(), and msg_box(). These two functions have nothing to do with the C-interface itself. I suppose they are there until you can think of a better category? How about 'User Interface'? Secondly, there are so many types that seem to be only implemented as functions. Why not implement them as types to extend their functionality? These types include isxdigit(), for example. Shawn Pringle -= B E G I N =- X-EUFORUM: 20307 Date: 2008 May 2 12:34 From: jiri babor Subject: Re: Namespace clobbering internals I must admit I have not followed your discussion from the start, but one simpler solution seems to me rather obvious: instead of adding ever more convoluted namespace rules, introduce a special, restricted type of global identifiers, which will have to be *always* preceded by a context specifier. A single new keyword will be required, say 'export' instead of 'global'. Using example similar to Jason's: -- map.e export type map(... export function new(... export function put(... export function find(... -- myprog.ex include map.e as map integer index map:map m m = map:new() m = map:put(m, "name", "Jason") index = map:find(m, "Jason") sequence e e = {1,2,3} ? find(3, e) -- system function not clobbered! The globals can stay as they are, but they should be used for important, system-wide identifiers only. Their wholesale use should be strongly discouraged. This approach will leave the global space uncluttered, programs more understandable, and not much, if any legacy code will be broken. jiri -= B E G I N =- X-EUFORUM: 20308 Date: 2008 May 2 13:20 From: Marco Achury Subject: Freedos package The Euphoria for DOS zip file has been included at FreeDOS repository. http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/euphoria/ Is not a real installer, just a zip file with installed system without the windows specific files. This is the first step to include it in a future FreeDOS release. +-+-+-+-+-+-+-+ Marco A. Achury Caracas, Venezuela -= B E G I N =- X-EUFORUM: 20309 Date: 2008 May 2 14:15 From: Jeremy Cowgar Subject: Re: New Docs, new layout Shawn Pringle wrote: > > Hey Jeremy, > > Two things: Firstly, I found two functions in the category 'C-Interface'; > free_console(), and msg_box(). These two functions have nothing to do with > the C-interface itself. I suppose they are there until you can think of a > better category? How about 'User Interface'? Yeah, I didn't like that either when I put them there, however, I did not categorize them as C-interface. In the current docs they are listed under C-interface, so I just stuck with it. http://rapideuphoria.com/library.htm#call_c_func >Secondly, there are so many > types that seem to be only implemented as functions. Why not implement them > as types to extend their functionality? These types include isxdigit(), > for example. I was thinking of that, but do we want types for all those C is??? functions? i.e. the types would be: alnum, alpha, ascii, cntrl, digit, graph, lower, print, punct, space, upper, xdigit ... some of thse in there we cannot use (lower, print, upper) and others would be confusing as a type (space, graph). I was unsure of exactly how to handle them. So, I found others using the names of the standard C functions found in ctypes.h, isascii, isdigit, etc... However, I think the section you found those in is called Type Checking, not really Types? -- Jeremy Cowgar http://jeremy.cowgar.com -= B E G I N =- X-EUFORUM: 20310 Date: 2008 May 2 14:17 From: Jeremy Cowgar Subject: Re: Namespace clobbering internals jiri babor wrote: > > > keyword will be required, say 'export' instead of 'global'. > I wonder if the inverse might be helpful? override ... for instance, say you want to override the print function: override function close(...) --- code end function Now, those that wish to override internals can, and those that just want to make their own close() function for a database, or a PDF writer, or who knows what, they can. -- Jeremy Cowgar http://jeremy.cowgar.com -= B E G I N =- X-EUFORUM: 20311 Date: 2008 May 2 14:22 From: Matt Lewis Subject: Re: Namespace clobbering internals jiri babor wrote: > > I must admit I have not followed your discussion from the start, but one > simpler solution seems to me rather obvious: instead of adding ever more > convoluted namespace rules, introduce a special, restricted type of global > identifiers, which will have to be *always* preceded by a context specifier. > A single new keyword will be required, say 'export' instead of 'global'. Of *course* it's obvious to you, Jiri. Seriously, though, it's good to hear from you again. > The globals can stay as they are, but they should be used for important, > system-wide identifiers only. Their wholesale use should be strongly > discouraged. > > This approach will leave the global space uncluttered, programs more > understandable, and not much, if any legacy code will be broken. Yes, this gets into the 'packaging' topic that has been discussed a bit. I think this is very similar to what I've proposed in that arena. I'd add a little to this idea, to say that you have to use the namespace that is specific to that file, because a namespace also can apply to the globals included by the file given the namespace. -- app.ex include foo.e as foo include bar.e as bar foo:baz() -- ok bar:bar() -- ok foo:bar() -- error! -- foo.e include bar.e as bar ... bar:bar() -- bar.e export procedure bar() end procedure global procedure baz() end procedure I like this because no matter where bar.e goes, the behavior stays the same, and it's scope is obvious. I'm contrasting this to CChris' packaging proposal, where we would have to add some additional packaging information in other files. This would allow library writers to spread out among multiple files (making their lives easier) but without exposing the internals to library users, who can possibly come to rely on something meant to be internal, and subject to change without notice. Matt -= B E G I N =- X-EUFORUM: 20312 Date: 2008 May 2 14:36 From: Jeremy Cowgar Subject: Re: Namespace clobbering internals I don't know if anyone else is, but I'm having troubles following all the suggestions, the pros/cons, etc... I wonder if we should create a wiki page for a Namespace plan or something? Seems kind of hard to act on any of this because it seems we've made no decision and it's hard to even decide what choices there are to make a decision about, or for that matter, what the problem actually is any more :-) -- Jeremy Cowgar http://jeremy.cowgar.com -= B E G I N =- X-EUFORUM: 20313 Date: 2008 May 2 16:41 From: C Bouzy Subject: Re: Win32Lib Error Fixes Hello CChris, Actually it wouldn't hurt to put it in both places. In regards to the Defprocessing error, lResult will return something unexpected or nothing at all. ~C Bouzy "If you do what you have always done, you will get what you always got." -= B E G I N =- X-EUFORUM: 20314 Date: 2008 May 2 17:18 From: Jeremy Cowgar Subject: locale support? I finished documenting datetime.e: http://jeremy.cowgar.com/euphoria/lib_dtm.htm And it has a format function that allows you to: d = new(2008, 5, 2, 12, 58, 32) s = format(d, "%A, %B %d '%y %H:%M%p") -- s is "Friday, May 2 '08 12:58PM" So, the problem is not that the format function cannot support other languages (because it can), but how to deal with locale support. Right now, in datetime.e there are a few sequences titled things like: month_names, month_abbrs, day_names, day_abbrs. Those are global sequences that format() uses to populate the resulting string with. If you do not speak English, you can easily change the content of those global sequences and format will happily use your language to format the date/time. However, do we need a greater support? i.e. should I introduce a locale.e or something? For instance, the GNU C locale support has abilities for dates, times, numbers, money, etc... -- Jeremy Cowgar http://jeremy.cowgar.com -= B E G I N =- X-EUFORUM: 20315 Date: 2008 May 2 18:05 From: Matt Lewis Subject: Re: Namespace clobbering internals Jeremy Cowgar wrote: > > I don't know if anyone else is, but I'm having troubles following all the suggestions, > the pros/cons, etc... I wonder if we should create a wiki page for a Namespace plan or > something? Seems kind of hard to act on any of this because it seems we've made no decision > and it's hard to even decide what choices there are to make a decision about, or for > that matter, what the problem actually is any more :-) In fact, there already is one, although it's out of date now, as it describes stuff already implemented: http://rapideuphoria.wiki.sourceforge.net/Namespace_Resolution Matt -= B E G I N =- X-EUFORUM: 20316 Date: 2008 May 2 18:27 From: Ryan W. Johnson Subject: Re: locale support? Yes, it would be great if the app could use format dates, times, etc. according to the OS settings. ~Ryan W. Johnson Fluid Application Environment http://www.fluidae.com/ [cool quote here, if i ever think of one...] -= B E G I N =- X-EUFORUM: 20317 Date: 2008 May 2 20:31 From: Jeremy Cowgar Subject: All current functions documented Ok, I just documented about 20 functions this afternoon that were previously in the standard library but not yet documented. Now's your chance to get a preview of the new doc layout and all the functions that currently exist in Euphoria 3.2/4.0. http://jeremy.cowgar.com/euphoria/library.htm -- Jeremy Cowgar http://jeremy.cowgar.com -= B E G I N =- X-EUFORUM: 20318 Date: 2008 May 2 20:36 From: Salix Subject: Re: Freedos package Just a quick note. Thank you for taking care of the DOS distribution. I am proud to see Euphoria in FreeDOS repository. Regards, Salix -= B E G I N =- X-EUFORUM: 20319 Date: 2008 May 2 20:55 From: c.k.lester Subject: Re: All current functions documented Jeremy Cowgar wrote: > > Now's your chance to get a preview > of the new doc layout and all the functions that currently exist in Euphoria > 3.2/4.0. Great job, Jeremy! I think you can safely call it 4.0 from now on. ;) -= B E G I N =- X-EUFORUM: 20320 Date: 2008 May 2 22:16 From: Alan F Subject: Re: New Docs, new layout Jeremy Cowgar wrote: > > Shawn Pringle wrote: > > > > Hey Jeremy, > > > >Secondly, there are so many > > types that seem to be only implemented as functions. Why not implement them > > as types to extend their functionality? These types include isxdigit(), > > for example. > > I was thinking of that, but do we want types for all those C is??? functions? > i.e. the types would be: alnum, alpha, ascii, cntrl, digit, graph, lower, print, > punct, space, upper, xdigit ... some of thse in there we cannot use (lower, > print, upper) and others would be confusing as a type (space, graph). > I think it would be useful to have these as types rather than simply as functions, but I agree that simply leaving the 'is' and dropping it entirely to make the type name is not ideal. Perhaps some sort of prefix, like 't_', in front of the name, so we have t_alnum, t_alpha, etc. -= B E G I N =- X-EUFORUM: 20321 Date: 2008 May 2 22:40 From: CChris Subject: Re: Win32Lib Error Fixes C Bouzy wrote: > > Hello CChris, > > Actually it wouldn't hurt to put it in both places. In regards to the Defprocessing > error, lResult will return something unexpected or nothing at all. > > ~C Bouzy > > "If you do what you have always done, you will get what you always got." It won't hurt, just perhaps a little puzzling for any future maintainer. As for DefProcessing, then i'll put your code with a comment about the condition you experienced. Doesn't this result from an OS thread switch, by any chance? CChris -= B E G I N =- X-EUFORUM: 20322 Date: 2008 May 2 23:39 From: Alex Caracatsanis Subject: [DOS] Display Copyright Symbol Hi folks Can someone please tell me what code will result in the display of a copyright symbol (ASCII value ©) on the console? Thank you Alex Caracatsanis -= B E G I N =- X-EUFORUM: 20323 Date: 2008 May 3 0:10 From: Larry Miller Subject: Re: [DOS] Display Copyright Symbol Alex Caracatsanis wrote: > > Hi folks > > Can someone please tell me what code will result in the display of a > copyright symbol (ASCII value ©) on the console? > > Thank you > > Alex Caracatsanis I am assuming you are using a console window with Windows. The default font used on the console does not have the copyright symbol. Many of the special symbols were sacrificed for the line drawing characters. To display the copyright character you will have to change the font by using console properties to Lucida Console. Larry Miller -= B E G I N =- X-EUFORUM: 20324 Date: 2008 May 3 0:26 From: Alex Caracatsanis Subject: [DOS32] Fonts for Console Display? Another quick question... Is it possible to use a variety of fonts to display output on the console? Can you display something in italics, for example, or change the size of letters? (WinXP) Thank you Alex Caracatsanis -= B E G I N =- X-EUFORUM: 20325 Date: 2008 May 3 0:32 From: Alex Caracatsanis Subject: Re: [DOS] Display Copyright Symbol - END Larry Miller wrote: > > Alex Caracatsanis wrote: > > > > Can someone please tell me what code will result in the display of a > > copyright symbol (ASCII value ©) on the console? > > To display the copyright character you will have to change the font by > using console properties to Lucida Console. > Larry Miller Thanks Larry. I think you might have also answered my next post. Alex -= B E G I N =- X-EUFORUM: 20326 Date: 2008 May 3 0:36 From: Larry Miller Subject: Re: [DOS32] Fonts for Console Display? Alex Caracatsanis wrote: > > Another quick question... > > Is it possible to use a variety of fonts to display output on the console? > Can you display something in italics, for example, or change the size of > letters? (WinXP) > > Thank you > > Alex Caracatsanis I suppose this could be done but it would not be easy. Windows provides very little support for this kind of thing on a console window. DOS provides even less. In any case this is well beyond anything I have even attempted. Larry Miller -= B E G I N =- X-EUFORUM: 20327 Date: 2008 May 3 1:24 From: Alex Caracatsanis Subject: Re: [DOS32] Fonts for Console Display? - END Larry Miller wrote: > > Alex Caracatsanis wrote: > > > > Is it possible to use a variety of fonts to display output on the console? > I suppose this could be done but it would not be easy. Thanks Larry. That's good enough for me. Alex -= B E G I N =- X-EUFORUM: 20328 Date: 2008 May 3 4:27 From: don cole Subject: Button Aesthetics Hello, My fellow Euphorians, How can I make the text of a Button look like this: C l o s e with IDE? Don Cole -= B E G I N =- X-EUFORUM: 20329 Date: 2008 May 3 5:30 From: C Bouzy Subject: Re: Win32Lib Error Fixes Hello CChris, I wish I could tell you what causes the error, but I have never been able to reproduce the error on-demand. It just happens randomly and only with certain types of apps. ~C Bouzy "If you do what you have always done, you will get what you always got." -= B E G I N =- X-EUFORUM: 20330 Date: 2008 May 3 9:51 From: Judith Evans Subject: Re: Button Aesthetics don cole wrote: > > > Hello, My fellow Euphorians, > > How can I make the text of a Button look like this: > > C > l > o > s > e > Enter the caption as C\nl\no\ns\ne and in Properties OtherStyles check multiline. judith > with IDE? > > Don Cole -= B E G I N =- X-EUFORUM: 20331 Date: 2008 May 3 13:23 From: Greg Haberek Subject: Re: [DOS32] Fonts for Console Display? - END Alex Caracatsanis wrote: > > Larry Miller wrote: > > > > I suppose this could be done but it would not be easy. > > Thanks Larry. That's good enough for me. > > Alex Alex, Are you actually programming in DOS, or the Windows console? If you're using pure DOS, Jiri Babor has some amazing graphical font routines in the Archive. If you're using Windows, then perhaps you could make your own "console" in Win32Lib? -Greg -= B E G I N =- X-EUFORUM: 20332 Date: 2008 May 3 13:42 From: Greg Haberek Subject: Re: Button Aesthetics Judith Evans wrote: > > Enter the caption as C\nl\no\ns\ne and in Properties OtherStyles check multiline. Judith, are you still working on your colored buttons library? Perhaps this could be of some use. I haven't been using it in a while. You could make rotated buttons with it. global procedure setFontRotated( integer pId, sequence pFont, integer pSize, integer pStyle, integer pAngle ) pAngle *= 10 while pAngle < 0 do pAngle += 3600 end while while pAngle > 3600 do pAngle -= 3600 end while setFont( pId, pFont, pSize, {pStyle,0,pAngle,pAngle,DEFAULT_CHARSET,0,0,0,0} ) end procedure -Greg -= B E G I N =- X-EUFORUM: 20333 Date: 2008 May 3 14:06 From: Bernie Ryan Subject: Re: [DOS] Display Copyright Symbol Alex Caracatsanis wrote: > > Hi folks > > Can someone please tell me what code will result in the display of a > copyright symbol (ASCII value ©) on the console? > > Thank you > > Alex Caracatsanis I think if you try #251 in a windows text string that may work. Bernie My files in archive: WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API Can be downloaded here: http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan -= B E G I N =- X-EUFORUM: 20334 Date: 2008 May 3 14:15 From: Bernie Ryan Subject: Re: [DOS] Display Copyright Symbol Bernie Ryan wrote: > > Alex Caracatsanis wrote: > > > > Hi folks > > > > Can someone please tell me what code will result in the display of a > > copyright symbol (ASCII value ©) on the console? > > > > Thank you > > > > Alex Caracatsanis > > I think if you try #251 in a windows text string that may work. > > Bernie > > My files in archive: > WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API > > Can be downloaded here: > http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan CORRECTION THAT SHOULD BE " \251 " ( the slash has to be there no # sign ) I haven't woke up yet. Bernie My files in archive: WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API Can be downloaded here: http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan -= B E G I N =- X-EUFORUM: 20335 Date: 2008 May 3 14:15 From: don cole Subject: Re: Button Aesthetics Judith Evans wrote: > > don cole wrote: > > > > > > Hello, My fellow Euphorians, > > > > How can I make the text of a Button look like this: > > > > C > > l > > o > > s > > e > > > > Enter the caption as C\nl\no\ns\ne and in Properties OtherStyles check multiline. > > judith > > with IDE? > > > > Don Cole Thank you Judth, When I highlite the button and right click properties nothing happens. I'm using version 0.22.0 Don Cole -= B E G I N =- X-EUFORUM: 20336 Date: 2008 May 3 14:15 From: Jason Gade Subject: Re: Namespace clobbering internals Jeremy Cowgar wrote: > > jiri babor wrote: > > > > > > keyword will be required, say 'export' instead of 'global'. > > > > I wonder if the inverse might be helpful? override ... for instance, say you > want to override the print function: > > > override function close(...) > --- code > end function > > > Now, those that wish to override internals can, and those that just want to > make their own close() function for a database, or a PDF writer, or who knows > what, they can. > > -- > Jeremy Cowgar > http://jeremy.cowgar.com You know, I was reading some Python docs last night, for no particular reason, and one of their standards and practices for naming routines that might clash with a built-in is to append an underscore to the identifier: function open_(sequence name) -- Do stuff here end function Not a permanent solution because we really do need to decide how scopes and namespaces should work better, but maybe a good temporary solution since we never seem to be able to come to a consensus. -- A complex system that works is invariably found to have evolved from a simple system that works. --John Gall's 15th law of Systemantics. "Premature optimization is the root of all evil in programming." --C.A.R. Hoare j. -= B E G I N =- X-EUFORUM: 20337 Date: 2008 May 3 14:18 From: don cole Subject: Judith never mind I see it now. Also I like t6he idea of rotating buttons. Don Cole -= B E G I N =- X-EUFORUM: 20338 Date: 2008 May 3 14:25 From: Jeremy Cowgar Subject: Re: 3.2, Wrapping DLLs and Float types Ok. I installed gcc-3.3 on my computer and Euphoria 3.2/4.0 works fine, floats and all when compiled with gcc-3.3. It works fine when compiled with gcc-4.3.0, except when using floats. So, the problem is with something changing in gcc. I am just not sure what. I am going to start a new thread about Euphoria and gcc-4.3.0 compatibility. Please comment there (so we can have proper subject titles). -- Jeremy Cowgar http://jeremy.cowgar.com -= B E G I N =- X-EUFORUM: 20339 Date: 2008 May 3 14:34 From: Jeremy Cowgar Subject: Euphoria and gcc-4.3.0 compatibility I made a change to the gcc call stack offset for version 4.3.0 of gcc, with the help of Matt. Once I made this change things seemed to work just fine with gcc 4.3.0, however, later I realized that when calling a function with C_FLOAT types, there is some mangling there. Sometimes the output of the C function using the C_FLOAT is zero, other times it is 1 parameter off. I have not tested other types. How can we resolve this as a lot of Linux distributions are either at or moving toward gcc 4.3 for their standard compiler, making Euphoria incompatible with many Linux distributions. Now, I should have prefixed the above with, if the user chooses to compile from source, which many do, and also if we wish to get Euphoria into major distributions, they will compile from source most likely. -- Jeremy Cowgar http://jeremy.cowgar.com -= B E G I N =- X-EUFORUM: 20340 Date: 2008 May 3 14:50 From: Jeremy Cowgar Subject: Organization (was Re: Namespace clobbering internals) Jason Gade wrote: > > Not a permanent solution because we really do need to decide how scopes and > namespaces should work better, but maybe a good temporary solution since we > never seem to be able to come to a consensus. > I've been a long time Euphoria user but not always active on EUforum but one of the things it seems to me about Euphoria is we cannot make a decision, therefore, a lot of things that could make the language nicer are never done. I do not think this is the fault of anyone here, I think we may just need a bit more organization. The forums are great for discussing topics, but I really think we need to start using a wiki a bit. I know there is one on SF for Euphoria and then there is http://euwiki.ayo.biz/Main_Page . It's just an opinion, but I think the SF wiki is too slow and people are discouraged waiting for it all the time and Media Wiki is too complex for a simple wiki. However, either will work. What I think we need is a wiki page first of all describing the problem we face. Then let people add their suggested solutions. Discussion can then take place here about suggested solutions. As we find pro's/con's, those should be added to the wiki page under the proposed solution. Once discussion on the solutions is complete, review what is on the Wiki. My guess is a lot of solutions could simply be removed because the con's outweigh the pro's. We will then be down to a few solutions. Discussion should then start comparing solution A to solution B and eventually we are down to 1 solution. It can then turn into a task to be completed. As it stands now we rarely get to a task to be completed, thus, nothing is ever done about it. There is a saying, "A good plan today is better than a perfect one tomorrow." While this is not totally true in application to a programming language, its message has truth for us. Other languages have very structured processes to complete such tasks as I've outlined. I'm not suggesting that we become so structured we have to create an organizing body to oversee the language, but I am suggesting that we organize better. Thoughts? -- Jeremy Cowgar http://jeremy.cowgar.com -= B E G I N =- X-EUFORUM: 20341 Date: 2008 May 3 14:54 From: Bernie Ryan Subject: Re: Euphoria and gcc-4.3.0 compatibility Jeremy Cowgar wrote: > I have not tested other types. How can we resolve this as a lot of Linux distributions > are either at or moving toward gcc 4.3 for their standard compiler, making Euphoria > incompatible with many Linux distributions. > > Now, I should have prefixed the above with, if the user chooses to compile from > source, which many do, and also if we wish to get Euphoria into major distributions, > they will compile from source most likely. If you are distributing source for Linux I think your distribution should be checking for any necessary dependence for that compile. Bernie My files in archive: WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API Can be downloaded here: http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan -= B E G I N =- X-EUFORUM: 20342 Date: 2008 May 3 14:59 From: Jeremy Cowgar Subject: Re: Euphoria and gcc-4.3.0 compatibility Bernie Ryan wrote: > > If you are distributing source for Linux I think your distribution > should be checking for any necessary dependence for that compile. > We do distribute source, anyone can download it from rapideuphoria.com. It's not as easy as checking dependencies. For instance, a dependency is liba or libb not being present. The user can then install liba or libb. With gcc, most distributions are built on 1 version of gcc and it's not a matter of installing gcc version 4.1 or 4.2, etc... It is that you have gcc-4.3.0 and that's it. For the average user, they are not going to be able to deal with multiple versions of gcc. Fact of the matter is, Euphoria should compile w/o problem on 4.3.0. We need to fix Euphoria for it to do so. Currently there are different #ifdef/#else/#endif statements in the source code to make it work on different versions of gcc, and that is the proper way to fix this problem. The proper way is not to say the user must have 4.1 installed or 3.3. -- Jeremy Cowgar http://jeremy.cowgar.com -= B E G I N =- X-EUFORUM: 20343 Date: 2008 May 3 15:15 From: Bernie Ryan Subject: Re: Euphoria and gcc-4.3.0 compatibility Jeremy Cowgar wrote: > We do distribute source, anyone can download it from rapideuphoria.com. It's > not as easy as checking dependencies. For instance, a dependency is liba or > libb not being present. The user can then install liba or libb. With gcc, most > distributions are built on 1 version of gcc and it's not a matter of installing > gcc version 4.1 or 4.2, etc... It is that you have gcc-4.3.0 and that's it. > For the average user, they are not going to be able to deal with multiple versions > of gcc. > > Fact of the matter is, Euphoria should compile w/o problem on 4.3.0. We need > to fix Euphoria for it to do so. Currently there are different #ifdef/#else/#endif > statements in the source code to make it work on different versions of gcc, > and that is the proper way to fix this problem. The proper way is not to say > the user must have 4.1 installed or 3.3. > Jeremy: What I am saying is that most LINUX program distributions that I have downloaded and installed automatically checked dependencies before installation and you expect the average user to compile exu on their system Euphoria MUST be available in that form. Bernie My files in archive: WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API Can be downloaded here: http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan -= B E G I N =- X-EUFORUM: 20344 Date: 2008 May 3 15:18 From: Jeremy Cowgar Subject: Re: Euphoria and gcc-4.3.0 compatibility Bernie Ryan wrote: > > > What I am saying is that most LINUX program distributions that > I have downloaded and installed automatically checked dependencies > before installation and you expect the average user to compile exu > on their system Euphoria MUST be available in that form. I'm not sure I follow what your saying. Euphoria really has no dependencies. Just a working compiler. -- Jeremy Cowgar http://jeremy.cowgar.com -= B E G I N =- X-EUFORUM: 20345 Date: 2008 May 3 15:35 From: Jason Gade Subject: Re: Euphoria and gcc-4.3.0 compatibility Jeremy Cowgar wrote: > > Bernie Ryan wrote: > > > > > > What I am saying is that most LINUX program distributions that > > I have downloaded and installed automatically checked dependencies > > before installation and you expect the average user to compile exu > > on their system Euphoria MUST be available in that form. > > I'm not sure I follow what your saying. Euphoria really has no dependencies. > Just a working compiler. > > -- > Jeremy Cowgar > http://jeremy.cowgar.com Like Jeremy said, the Euphoria binary doesn't really have any dependencies. The average user probably won't be compiling from source, either. But Linux users are more likely to do so than Windows users. I think that Matt or someone made a .deb package for installing the Euphoria binary with apt. I think that it's a work in progress though. Oh, yeah. It's on the sourceforge site and it's labeled "3.2.0.alpha-1". Jeremy's problem with compiling under gcc 4.3.0 is finding what the difference is with that version of gcc from previous versions so that the source can be modified to fix that. The #ifdefs take care of the dependency. -- A complex system that works is invariably found to have evolved from a simple system that works. --John Gall's 15th law of Systemantics. "Premature optimization is the root of all evil in programming." --C.A.R. Hoare j. -= B E G I N =- X-EUFORUM: 20346 Date: 2008 May 3 15:49 From: Matt Lewis Subject: Re: Euphoria and gcc-4.3.0 compatibility Bernie Ryan wrote: > > Jeremy Cowgar wrote: > > > > I have not tested other types. How can we resolve this as a lot of Linux > > distributions are either at or moving toward gcc 4.3 for their standard > > compiler, making Euphoria incompatible with many Linux distributions. > > > > Now, I should have prefixed the above with, if the user chooses to compile > > from source, which many do, and also if we wish to get Euphoria into major > > distributions, they will compile from source most likely. > > If you are distributing source for Linux I think your distribution > should be checking for any necessary dependence for that compile. That's the point of a package in a package management system. However, your comment has nothing to do with Jeremy's. Matt -= B E G I N =- X-EUFORUM: 20347 Date: 2008 May 3 16:01 From: Matt Lewis Subject: Re: Euphoria and gcc-4.3.0 compatibility Jeremy Cowgar wrote: > > I made a change to the gcc call stack offset for version 4.3.0 of gcc, with > the help of Matt. Once I made this change things seemed to work just fine with > gcc 4.3.0, however, later I realized that when calling a function with C_FLOAT > types, there is some mangling there. Sometimes the output of the C function > using the C_FLOAT is zero, other times it is 1 parameter off. From: http://gcc.gnu.org/gcc-4.3/changes.html * Starting from GCC 4.3.1, decimal floating point variables are aligned to their natural boundaries when they are passed on stack for i386. Could you write a very simple program that passes the types of arguments that you're passing and compile it to asm? Then we could take a look to see what it's doing. Matt -= B E G I N =- X-EUFORUM: 20348 Date: 2008 May 3 16:10 From: Bernie Ryan Subject: Re: Euphoria and gcc-4.3.0 compatibility Matt Lewis wrote: > > That's the point of a package in a package management system. However, > your comment has nothing to do with Jeremy's. > Matt: I have seen some programs that only will compile with older versions gcc and the package manager would refuse to install from source using new version of gcc because of dependencies. As far as the #if conditionals in the source is a problem; That is why I have said in the past a new interpreter version needs to be written for each platform to eliminate this patch-work of code. Bernie My files in archive: WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API Can be downloaded here: http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan -= B E G I N =- X-EUFORUM: 20349 Date: 2008 May 3 16:15 From: Jeremy Cowgar Subject: Re: Euphoria and gcc-4.3.0 compatibility Matt Lewis wrote: > > Could you write a very simple program that passes the types of arguments > that you're passing and compile it to asm? Then we could take a look to > see what it's doing. > Hm, my gcc reports: $ gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../configure --prefix=/usr --enable-shared --enable-languages=c,c++,fortran,objc,obj-c++,treelang --enable-threads=posix --mandir=/usr/share/man --enable-__cxa_atexit --disable-multilib --libdir=/usr/lib --libexecdir=/usr/lib --enable-clocale=gnu --disable-libstdcxx-pch --with-tune=generic Thread model: posix gcc version 4.3.0 (GCC) However, here is the C program: float hello(float abc) { return abc; } int main(int argc, char **argv) { hello(12.5); return 0; } Here is the assembler output: .file "hello.c" .text .globl hello .type hello, @function hello: pushl %ebp movl %esp, %ebp subl $4, %esp movl 8(%ebp), %eax movl %eax, -4(%ebp) flds -4(%ebp) leave ret .size hello, .-hello .globl main .type main, @function main: leal 4(%esp), %ecx andl $-16, %esp pushl -4(%ecx) pushl %ebp movl %esp, %ebp pushl %ecx subl $4, %esp movl $0x41480000, %eax movl %eax, (%esp) call hello fstp %st(0) movl $0, %eax addl $4, %esp popl %ecx popl %ebp leal -4(%ecx), %esp ret .size main, .-main .ident "GCC: (GNU) 4.3.0" .section .note.GNU-stack,"",@progbits -- Jeremy Cowgar http://jeremy.cowgar.com -= B E G I N =- X-EUFORUM: 20350 Date: 2008 May 3 16:15 From: Bernie Ryan Subject: Re: Euphoria and gcc-4.3.0 compatibility Whoops I return key before finishing my post I understand why the code was written with the conditionals to make easier for Rob to maintain the code for all platforms. But now I think it would be easier to maintain if it was broke out into different platforms. Bernie My files in archive: WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API Can be downloaded here: http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan -= B E G I N =- X-EUFORUM: 20351 Date: 2008 May 3 17:16 From: Jeremy Cowgar Subject: Re: Euphoria and gcc-4.3.0 compatibility Bernie Ryan wrote: > > I understand why the code was written with the conditionals to > make easier for Rob to maintain the code for all platforms. > But now I think it would be easier to maintain if it was broke out > into different platforms. > The section of code in question is switching 2 define statements, it'd be a bummer to move to a complex system of multiple source files, determining the platform, optionally switching different files in and out for just 2 lines of code that are different. Here's an example, the LCC and DJGPP #if/else/endif: #ifdef ELCC #define push() _asm("pushl -8(%ebp)") #define pop() _asm("addl -36(%ebp), %esp") #endif #ifdef EDJGPP #define push() asm("pushl -4(%ebp)") #define pop() #endif -- Jeremy Cowgar http://jeremy.cowgar.com -= B E G I N =- X-EUFORUM: 20352 Date: 2008 May 3 17:22 From: Matt Lewis Subject: Re: Euphoria and gcc-4.3.0 compatibility Bernie Ryan wrote: > > > Whoops I return key before finishing my post > I understand why the code was written with the conditionals to > make easier for Rob to maintain the code for all platforms. > But now I think it would be easier to maintain if it was broke out > into different platforms. I couldn't disagree with this more. Matt -= B E G I N =- X-EUFORUM: 20353 Date: 2008 May 3 18:24 From: Judith Evans Subject: Re: Button Aesthetics Greg Haberek wrote: > > Judith Evans wrote: > > > > Enter the caption as C\nl\no\ns\ne and in Properties OtherStyles check multiline. > > Judith, are you still working on your colored buttons library? Perhaps this > could be of some use. I haven't been using it in a while. You could make rotated > buttons with it. > > > global procedure setFontRotated( integer pId, sequence pFont, integer pSize, integer pStyle, integer > pAngle ) > > > pAngle *= 10 > > > while pAngle < 0 do > > pAngle += 3600 > > end while > > > while pAngle > 3600 do > > pAngle -= 3600 > > end while > > > setFont( pId, pFont, pSize, {pStyle,0,pAngle,pAngle,DEFAULT_CHARSET,0,0,0,0} ) > > > end procedure > > > > -Greg I really like this and I always like getting contributions. Rotating the text works nicely. I need a routine to "rotate" the drawn button -- you wouldn't have one handy ..... would you? Thanks for the contribution to colored buttons. judith -= B E G I N =- X-EUFORUM: 20354 Date: 2008 May 3 20:42 From: CChris Subject: Re: Win32Lib Error Fixes C Bouzy wrote: > > Hello CChris, > > I wish I could tell you what causes the error, but I have never been able to > reproduce the error on-demand. It just happens randomly and only with certain > types of apps. > > ~C Bouzy > > "If you do what you have always done, you will get what you always got." Ok; this confirms my gut feelings about a race condition. At any rate I have include the code you posted, with a note for any future maintainer (or me 12 month from now). CChris -= B E G I N =- X-EUFORUM: 20355 Date: 2008 May 3 22:22 From: Shawn Pringle Subject: building EUPHORIA on Linux I have been experimenting with EUPHORIA 3.1 on Linux. After building the interpreter I found that the qsort.exw demo freezes with the interpreter I built. After displaying the unsorted list it gets stuck in the qsort() call. The interpreter distributed with EUPHORIA doesn't have this bahavior, however. A log of my shell follows. I reunpacked from sources. Recompiled. Ran it and ran it again with strace. pringles@piva:~/bin/euphoria/source$ uname -a Linux piva 2.6.18-6-686 #1 SMP Sun Feb 10 22:11:31 UTC 2008 i686 GNU/Linux pringles@piva:~/bin/euphoria/source$ tar -xzf ~/Desktop/Downloads/euphor31.tar -C ~/bin pringles@piva:~/bin/euphoria/source$ make make: Nothing to be done for `all'. pringles@piva:~/bin/euphoria/source$ make clean rm main-.c rm *.o pringles@piva:~/bin/euphoria/source$ make exu ec.ex int.ex make: exu: Command not found make: *** [main-.o] Error 127 pringles@piva:~/bin/euphoria/source$ PATH="/home/pringles/bin/euphoria/bin:$PATH" make exu ec.ex int.ex 21 .c files were created. To build your executable file, type: ./emake gcc -c -w -fsigned-char -O2 -ffast-math -fomit-frame-pointer main-.c gcc -c -w -fsigned-char -O2 -ffast-math -fomit-frame-pointer main-0.c gcc -c -w -fsigned-char -O2 -ffast-math -fomit-frame-pointer pathopen.c gcc -c -w -fsigned-char -O2 -ffast-math -fomit-frame-pointer init-.c gcc -c -w -fsigned-char -O2 -ffast-math -fomit-frame-pointer wildcard.c gcc -c -w -fsigned-char -O2 -ffast-math -fomit-frame-pointer file.c gcc -c -w -fsigned-char -O2 -ffast-math -fomit-frame-pointer error.c gcc -c -w -fsigned-char -O2 -ffast-math -fomit-frame-pointer machine.c gcc -c -w -fsigned-char -O2 -ffast-math -fomit-frame-pointer symtab.c gcc -c -w -fsigned-char -O2 -ffast-math -fomit-frame-pointer scanner.c gcc -c -w -fsigned-char -O2 -ffast-math -fomit-frame-pointer scanne_0.c gcc -c -w -fsigned-char -O2 -ffast-math -fomit-frame-pointer main.c gcc -c -w -fsigned-char -O2 -ffast-math -fomit-frame-pointer emit.c gcc -c -w -fsigned-char -O2 -ffast-math -fomit-frame-pointer emit_0.c gcc -c -w -fsigned-char -O2 -ffast-math -fomit-frame-pointer emit_1.c gcc -c -w -fsigned-char -O2 -ffast-math -fomit-frame-pointer parser.c gcc -c -w -fsigned-char -O2 -ffast-math -fomit-frame-pointer parser_0.c gcc -c -w -fsigned-char -O2 -ffast-math -fomit-frame-pointer parser_1.c gcc -c -w -fsigned-char -O2 -ffast-math -fomit-frame-pointer backend.c gcc -c -w -fsigned-char -O2 -ffast-math -fomit-frame-pointer compress.c gcc -c -w -DELINUX -fsigned-char -O2 -ffast-math -fomit-frame-pointer be_execute.c gcc -c -w -DELINUX -fsigned-char -O2 -ffast-math -fomit-frame-pointer be_task.c gcc -c -w -DELINUX -fsigned-char -O2 -ffast-math -fomit-frame-pointer be_main.c gcc -c -w -DELINUX -fsigned-char -O2 -ffast-math -fomit-frame-pointer be_alloc.c gcc -c -w -DELINUX -fsigned-char -O2 -ffast-math -fno-defer-pop be_callc.c gcc -S -w -DELINUX -fsigned-char -O2 -ffast-math -fno-defer-pop be_callc.c gcc -finline-functions -c -w -DELINUX -fsigned-char -O2 -ffast-math -fomit-frame-pointer be_inline.c gcc -c -w -DELINUX -fsigned-char -O2 -ffast-math -fomit-frame-pointer be_machine.c gcc -c -w -DELINUX -fsigned-char -O -Os -fno-inline-functions -ffast-math -fomit-frame-pointer be_rterror.c gcc -c -w -DELINUX -fsigned-char -O -Os -fno-inline-functions -ffast-math -fomit-frame-pointer be_syncolor.c gcc -c -w -DELINUX -fsigned-char -O2 -ffast-math -fomit-frame-pointer be_runtime.c gcc -S -c -w -DELINUX -fsigned-char -O2 -ffast-math -fomit-frame-pointer be_runtime.c gcc -c -w -DELINUX -fsigned-char -O2 -ffast-math -fomit-frame-pointer be_symtab.c gcc -c -w -DELINUX -fsigned-char -O2 -ffast-math -fomit-frame-pointer be_w.c making exu gcc main-.o main-0.o pathopen.o init-.o wildcard.o file.o error.o machine.o symtab.o scanner.o scanne_0.o main.o emit.o emit_0.o emit_1.o parser.o parser_0.o parser_1.o backend.o compress.o be_execute.o be_task.o be_main.o be_alloc.o be_callc.o be_inline.o be_machine.o be_rterror.o be_syncolor.o be_runtime.o be_symtab.o be_w.o -lm -ldl -oexu pringles@piva:~/bin/euphoria/source$ exu ../demo/linux/qsort.exu bash: exu: command not found pringles@piva:~/bin/euphoria/source$ ./exu ../demo/linux/qsort.exu before sorting: {78,93,211,86,198,224,168,16,175,224,245,43,9,242,170,194,143,98,216, 79,103,84,248,153,165,199,77,29,4,148,192,180,77,53,161,15,216,94,54, 183,39,131,39,196,16,172,252,199,73,21} pringles@piva:~/bin/euphoria/source$ ./exu ../demo/linux/qsort.exu before sorting: {51,221,51,150,52,119,64,61,8,109,97,8,4,211,26,222,184,98,246,212, 128,46,85,113,99,220,184,251,42,180,25,150,139,61,34,27,113,34,221, 72,20,102,100,224,25,142,79,227,149,171} pringles@piva:~/bin/euphoria/source$ echo $EUDIR /home/pringles/bin/euphoria pringles@piva:~/bin/euphoria/source$ strace ./exu ../demo/linux/qsort.exu execve("./exu", ["./exu", "../demo/linux/qsort.exu"], [/* 33 vars */]) = 0 uname({sys="Linux", node="piva", ...}) = 0 brk(0) = 0x80c2000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f33000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/home/pringles/.libs/tls/i686/sse2/cmov/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/home/pringles/.libs/tls/i686/sse2/cmov", 0xbf884278) = -1 ENOENT (No such file or directory) open("/home/pringles/.libs/tls/i686/sse2/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/home/pringles/.libs/tls/i686/sse2", 0xbf884278) = -1 ENOENT (No such file or directory) open("/home/pringles/.libs/tls/i686/cmov/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/home/pringles/.libs/tls/i686/cmov", 0xbf884278) = -1 ENOENT (No such file or directory) open("/home/pringles/.libs/tls/i686/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/home/pringles/.libs/tls/i686", 0xbf884278) = -1 ENOENT (No such file or directory) open("/home/pringles/.libs/tls/sse2/cmov/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/home/pringles/.libs/tls/sse2/cmov", 0xbf884278) = -1 ENOENT (No such file or directory) open("/home/pringles/.libs/tls/sse2/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/home/pringles/.libs/tls/sse2", 0xbf884278) = -1 ENOENT (No such file or directory) open("/home/pringles/.libs/tls/cmov/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/home/pringles/.libs/tls/cmov", 0xbf884278) = -1 ENOENT (No such file or directory) open("/home/pringles/.libs/tls/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/home/pringles/.libs/tls", 0xbf884278) = -1 ENOENT (No such file or directory) open("/home/pringles/.libs/i686/sse2/cmov/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/home/pringles/.libs/i686/sse2/cmov", 0xbf884278) = -1 ENOENT (No such file or directory) open("/home/pringles/.libs/i686/sse2/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/home/pringles/.libs/i686/sse2", 0xbf884278) = -1 ENOENT (No such file or directory) open("/home/pringles/.libs/i686/cmov/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/home/pringles/.libs/i686/cmov", 0xbf884278) = -1 ENOENT (No such file or directory) open("/home/pringles/.libs/i686/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/home/pringles/.libs/i686", 0xbf884278) = -1 ENOENT (No such file or directory) open("/home/pringles/.libs/sse2/cmov/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/home/pringles/.libs/sse2/cmov", 0xbf884278) = -1 ENOENT (No such file or directory) open("/home/pringles/.libs/sse2/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/home/pringles/.libs/sse2", 0xbf884278) = -1 ENOENT (No such file or directory) open("/home/pringles/.libs/cmov/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/home/pringles/.libs/cmov", 0xbf884278) = -1 ENOENT (No such file or directory) open("/home/pringles/.libs/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/home/pringles/.libs", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=56498, ...}) = 0 mmap2(NULL, 56498, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f25000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/tls/i686/cmov/libm.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`3\0\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=145136, ...}) = 0 mmap2(NULL, 147584, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7f00000 mmap2(0xb7f23000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x22) = 0xb7f23000 close(3) = 0 open("/home/pringles/.libs/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/tls/i686/cmov/libdl.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20\f\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=9592, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7eff000 mmap2(NULL, 12404, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7efb000 mmap2(0xb7efd000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0xb7efd000 close(3) = 0 open("/home/pringles/.libs/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240O\1"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=1241392, ...}) = 0 mmap2(NULL, 1247388, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7dca000 mmap2(0xb7ef1000, 28672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x127) = 0xb7ef1000 mmap2(0xb7ef8000, 10396, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7ef8000 close(3) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7dc9000 mprotect(0xb7ef1000, 20480, PROT_READ) = 0 set_thread_area({entry_number:-1 -> 6, base_addr:0xb7dc96c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 munmap(0xb7f25000, 56498) = 0 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 ioctl(0, TIOCGWINSZ, {ws_row=24, ws_col=80, ws_xpixel=0, ws_ypixel=0}) = 0 brk(0) = 0x80c2000 brk(0x80e3000) = 0x80e3000 time(NULL) = 1209849081 open("/etc/localtime", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=1059, ...}) = 0 fstat64(3, {st_mode=S_IFREG|0644, st_size=1059, ...}) = 0 mmap2(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7da9000 read(3, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\6\0\0\0\6\0\0"..., 131072) = 1059 close(3) = 0 munmap(0xb7da9000, 131072) = 0 mprotect(0x80c8000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80cc000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 open("../demo/linux/qsort.exu", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=1253, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f32000 read(3, "-- Calling a Euphoria routine fr"..., 4096) = 1253 open("../demo/linux/dll.e", O_RDONLY) = -1 ENOENT (No such file or directory) open("../demo/linux/dll.e", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/pringles/bin/euphoria/include/dll.e", O_RDONLY) = 4 fstat64(4, {st_mode=S_IFREG|0644, st_size=2317, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f31000 read(4, "-- (c) Copyright 2007 Rapid Depl"..., 4096) = 2317 read(4, "", 4096) = 0 close(4) = 0 munmap(0xb7f31000, 4096) = 0 open("../demo/linux/machine.e", O_RDONLY) = -1 ENOENT (No such file or directory) open("../demo/linux/machine.e", O_RDONLY) = -1 ENOENT (No such file or directory) open("/home/pringles/bin/euphoria/include/machine.e", O_RDONLY) = 4 fstat64(4, {st_mode=S_IFREG|0644, st_size=9341, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f31000 read(4, "-- (c) Copyright 2007 Rapid Depl"..., 4096) = 4096 read(4, "\n-- bits 24-31} (most sign"..., 4096) = 4096 read(4, " machine_func(M_A_TO_F64, a)\nend"..., 4096) = 1149 read(4, "", 4096) = 0 close(4) = 0 munmap(0xb7f31000, 4096) = 0 read(3, "", 4096) = 0 close(3) = 0 munmap(0xb7f32000, 4096) = 0 mprotect(0x80dc000, 20480, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80da000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80db000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80da000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80cf000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80da000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80c9000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80da000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80da000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80da000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80ce000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80da000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80d4000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80d6000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80d1000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80da000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80d8000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80cc000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80d0000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80cc000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80d1000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80cc000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80d1000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80d7000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80d2000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80da000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80d6000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80da000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80d5000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80da000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80d7000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80da000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80d8000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80da000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80d9000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80da000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80d8000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80da000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80d6000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80da000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80e0000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80e0000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80da000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80e0000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80e1000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80e1000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80e1000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80d7000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80d8000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80e1000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80e1000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80e1000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80d7000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80e1000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80db000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80e1000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80da000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80e1000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80e1000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80e1000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80e1000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80e1000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80d9000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80e1000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80e1000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80e1000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80d7000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80e1000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80d6000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80e1000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80da000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80e1000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80e1000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80e1000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80e1000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80e1000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80d8000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80e1000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80d8000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80d8000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80d8000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80e1000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80e1000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80e1000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80e1000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80d8000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80d3000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80cc000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80d8000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 rt_sigaction(SIGINT, {0x8084eaf, [INT], SA_RESTART}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGILL, {0x80829a0, [ILL], SA_RESTART}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGSEGV, {0x80829a0, [SEGV], SA_RESTART}, {SIG_DFL}, 8) = 0 mprotect(0x80d8000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220T\1"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1147548, ...}) = 0 mmap2(NULL, 1157428, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7cae000 mmap2(0xb7dbf000, 28672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x110) = 0xb7dbf000 mmap2(0xb7dc6000, 10548, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7dc6000 close(3) = 0 mprotect(0xb7dbf000, 20480, PROT_READ) = 0 mprotect(0x80d4000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x80d1000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 1), ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f32000 write(1, "before sorting:", 15before sorting:) = 15 write(1, "\n", 1 ) = 1 write(1, "{171,62,11,229,207,155,230,200,1"..., 68{171,62,11,229,207,155,230,200,158,207,188,254,3,203,245,165,66,162,) = 68 write(1, "\n", 1 ) = 1 write(1, "127,246,134,37,45,103,82,161,20,"..., 67127,246,134,37,45,103,82,161,20,242,243,62,238,15,218,190,2,222,23,) = 67 write(1, "\n", 1 ) = 1 write(1, "19,7,235,142,223,179,166,218,134"..., 4619,7,235,142,223,179,166,218,134,36,43,105,80}) = 46 write(1, "\n", 1 ) = 1 futex(0x80d7228, FUTEX_WAIT, 2, NULL -= B E G I N =- X-EUFORUM: 20356 Date: 2008 May 3 22:42 From: Judith Evans Subject: Re: Button Aesthetics Greg Haberek wrote: > Judith, are you still working on your colored buttons library? Perhaps this > could be of some use. I haven't been using it in a while. You could make rotated > buttons with it. > > > global procedure setFontRotated( integer pId, sequence pFont, integer pSize, integer pStyle, integer > pAngle ) > > > pAngle *= 10 > > > while pAngle < 0 do > > pAngle += 3600 > > end while > > > while pAngle > 3600 do > > pAngle -= 3600 > > end while > > > setFont( pId, pFont, pSize, {pStyle,0,pAngle,pAngle,DEFAULT_CHARSET,0,0,0,0} ) > > > end procedure > > > > -Greg I've tested with various font names and notice MS Sans Serif, System, Courier and Fixedsys do not rotate. Do you know why? judith -= B E G I N =- X-EUFORUM: 20357 Date: 2008 May 3 23:06 From: "Gregory Haberek" Subject: Re: Button Aesthetics > posted by: Judith Evans > > I've tested with various font names and notice MS Sans Serif, System, Courier and Fixedsys do not rotate. Do you know why? Probably because they're not TrueType? -Greg -= B E G I N =- X-EUFORUM: 20358 Date: 2008 May 4 1:10 From: "Euler German" Subject: Re: locale support? > On 2 May 2008 at 10:18, Jeremy Cowgar wrote (maybe snipped): > > > posted by: Jeremy Cowgar > > I finished documenting datetime.e: > > http://jeremy.cowgar.com/euphoria/lib_dtm.htm > > And it has a format function that allows you to: > > > d = new(2008, 5, 2, 12, 58, 32) > s = format(d, "%A, %B %d '%y %H:%M%p") > -- s is "Friday, May 2 '08 12:58PM" > > > So, the problem is not that the format function cannot support other > languages (because it can), but how to deal with locale support. Right > now, in datetime.e there are a few sequences titled things like: > month_names, month_abbrs, day_names, day_abbrs. Those are global > sequences that format() uses to populate the resulting string with. > > If you do not speak English, you can easily change the content of > those global sequences and format will happily use your language to > format the date/time. However, do we need a greater support? i.e. > should I introduce a locale.e or something? > Definitely, yes! I fully support the motion and I'm voluteering to do my part in translation. All I need is original text in English and commenting for disambiguation. Question: would namespace be applicable here? So... d = br:new(2008, 5, 2, 12, 58, 32) s = format(d, "%A, %d de %B de %Y %H:%M") -- s is "Sexta, 2 de Maio de 2008 12:58" Best, Euler -- _ _| euler f german _| sete lagoas, mg, brazil _| efgerman{AT}gmail{DOT}com _| ----------------------------- _| Reply preferably to the list, _| or to the address above. Thx! -= B E G I N =- X-EUFORUM: 20359 Date: 2008 May 4 2:21 From: Ricardo Silva Veloso Subject: text_color() equivalent in C/C++ Wich is the equivalent to Euphoria text_color() in C/C++? Thanks. _______ http://pt.wikipedia.org/wiki/User:Ricvelozo -= B E G I N =- X-EUFORUM: 20360 Date: 2008 May 4 5:06 From: Marco Achury Subject: Re: Freedos package Salix wrote: > > Just a quick note. Thank you for taking care of the DOS distribution. I am proud > to see Euphoria in FreeDOS repository. > > Regards, > > Salix Yes, is nice to find Euphoria at ibiblio (and mirrors). FreeDOS has not oportunity to compete agains windows or linux as the main operative system for daily use. Except for people with very old hardware. But has some applications. FreeDOS has received a lot of free publicity from DELL that included the system as an option for people buying PCs. Video card manufacturers and others have included in the hardware a FreeDOS boot disk (CDROM or floppy) with tools to make bios updates and other maintenance work. There will be an impresive market for embebed applications like point of sale or industrial control computers. Look an example at: http://www.jkmicro.com/products/flashtcp.html This kind of equipment may receive a very small version of the interpreter, or Euphoria code translated and compiled on C. +-+-+-+-+-+-+-+ Marco A. Achury Caracas, Venezuela -= B E G I N =- X-EUFORUM: 20361 Date: 2008 May 4 5:20 From: Greg Haberek Subject: wxEditor Project As a change of pace, I'm starting to host some of my projects on SourceForge. My goal is to get others involved with my projects, so that many of my ideas can get off the ground. Otherwise, I seem to start projects on my own only to have them fizzle out as I lose interest. The first project of this is wxEditor. With Pete having dropped off the face of the planet (and Edita with him), and Euphoria 4.0 on the horizon, I figured I'd strike while the iron's hot. I just registered the project, so it's still in pending status. I'll collect the code I have so far and get it posted once the project's approved. http://sourceforge.net/projects/wxeditor/ Matt... this means I (we?) need to get wxStyledTextControl working. My efforts have been rather fruitless, and I just end up mangling C++ code in hopes I'll get something working. Right now, wxEditor operates as a basic text editor with multiple tabs, using wxNotebook and wxTextCtrl. I'd like to get the syntax highlighting working from the get-go. I see that as a major benefit to a code editor. -Greg -= B E G I N =- X-EUFORUM: 20362 Date: 2008 May 4 5:56 From: Marco Achury Subject: Re: [DOS] Display Copyright Symbol Larry Miller wrote: > > Alex Caracatsanis wrote: > > > > Hi folks > > > > Can someone please tell me what code will result in the display of a > > copyright symbol (ASCII value ©) on the console? > > > > Thank you > > > > Alex Caracatsanis > > I am assuming you are using a console window with Windows. > The default font used on the console does not have the copyright symbol. Many > of the special symbols were sacrificed for the line drawing characters. To display > the copyright character you will have to change the font by using console properties > to Lucida Console. > > Larry Miller On a real DOS system, the default US table code 437 doesn't includes that simbol. Multiligual Latin 1, the default for spanish and other languages included it as 184, 169 showed the symbol for Registered (R) +-+-+-+-+-+-+-+ Marco A. Achury Caracas, Venezuela -= B E G I N =- X-EUFORUM: 20363 Date: 2008 May 4 6:06 From: Marco Achury Subject: Re: [DOS32] Fonts for Console Display? > > Is it possible to use a variety of fonts to display output on the console? > > Can you display something in italics, for example, or change the size of > > letters? (WinXP) On a real DOS system you can manipulate the code page, the file or the copy on memory, to create your own customized characters. You can't go out of the rectangular area assigned to each character, so you are limited in change size. But I'm sure the windows emulation console will not enable you to make this. Of course you can create your own font file for windows with mixed normal + italic characters. Allways will be a lot of work. +-+-+-+-+-+-+-+ Marco A. Achury Caracas, Venezuela -= B E G I N =- X-EUFORUM: 20364 Date: 2008 May 4 13:16 From: CChris Subject: remainder() is not right The remainder of x by y, which remainder() is supposed to return, is the number with the smallest magnitude and the sign of y such that, if we call it z, x-z is a multiple of y. But remainder() has a quirkier response. For instance: ?remainder(-27,3600) -- -27, instead of 3573 ?remainder(-3627,3600) -- ditto ?remainder(-3627,-3600) -- -27 is correct here ?remainder(27,-3600) -- 27, instead of -3573 Changing remainder()'s behaviour will break any code that works around this behaviour. So perhaps should we add another function with the appropriate return values; perhaps signed_remainder()? Notionally, it might work like this: global function signed_remainder(object a,object b) integer atom_a,atom_b atom c if find(b,{{},0.0} then return {} -- not a valid 2nd argument -- crash("Invalid 2nd argument to remainder()") end if atom_a=atom(a) atom_b=atom(b) if atom_a!=atom_b then if atom_a then -- atom,sequence for i=1 to length(b) do b[i]=signed_remainder(a,b[i]) end for return b else -- sequence,atom for i=1 to length(a) do a[i]=signed_remainder(a[i],b) end for return a end if elsif atom_a=0 then -- two sequences if length(a)!=length(b) then return {} -- let caller handle the mismatch -- crash("Sequence lengths don't match") else for i=1 to length(a) do a[i]=signed_remainder(a[i],b[i]) end for return a end if else -- two atoms c=remainder(a,b) -- smallest magnitude and sign of a if a<0!=b<0 then return c+b else return c end if end function It will be probably better implemented as a builtin if there is a corresponding C stdlib function with the desired behaviour. If only to take advantage of the sequence extension mechanism binary_op() in be_runtime.c provides. CChris -= B E G I N =- X-EUFORUM: 20365 Date: 2008 May 4 14:32 From: "Euler German" Subject: Re: remainder() is not right > On 4 May 2008 at 6:16, CChris wrote (maybe snipped): > The remainder of x by y, which remainder() is supposed to return, is > the number with the smallest magnitude and the sign of y such that, if > we call it z, x-z is a multiple of y. > > But remainder() has a quirkier response. For instance: > ?remainder(-27,3600) -- -27, instead of 3573 > ?remainder(-3627,3600) -- ditto > ?remainder(-3627,-3600) -- -27 is correct here > ?remainder(27,-3600) -- 27, instead of -3573 > Chris, IMHO actual results are coherent to function's description found in Refman, or am I missing something? Isn't it supposed to return the remainder of division of the first element by the second? Best, Euler -- _ _| euler f german _| sete lagoas, mg, brazil _| efgerman{AT}gmail{DOT}com _| ----------------------------- _| Reply preferably to the list, _| or to the address above. Thx! -= B E G I N =- X-EUFORUM: 20366 Date: 2008 May 4 15:09 From: Jeremy Cowgar Subject: Formatting numbers/money according to Locale in Win32? Does anyone know how to format numbers/money in Win32 according to the locale? In linux, you simply use strfmon. I have localization complete in Linux. Just need the number/money formatting in Windows. I'm looking for a C api call. I see GetCurrencyFormat() but thus far have been unable to find where it's actually defined. All uses come back with a function id of -1. -- Jeremy Cowgar http://jeremy.cowgar.com -= B E G I N =- X-EUFORUM: 20367 Date: 2008 May 4 15:10 From: jacques deschênes Subject: Re: remainder() is not right I get the same result as euphoria with the following C code compiled with bcc55 #include int main(int argc, char** argv){ printf("%d\n",-27 % 3600); printf("%d\n",-3627 % 3600); printf("%d\n",-3627 % -3600); printf("%d\n",27 % -3600); } Jacques Deschênes CChris wrote: > > > The remainder of x by y, which remainder() is supposed to return, is the number > with the smallest magnitude and the sign of y such that, if we call it z, x-z > is a multiple of y. > > But remainder() has a quirkier response. For instance: > ?remainder(-27,3600) -- -27, instead of 3573 > ?remainder(-3627,3600) -- ditto > ?remainder(-3627,-3600) -- -27 is correct here > ?remainder(27,-3600) -- 27, instead of -3573 > > Changing remainder()'s behaviour will break any code that works around this > behaviour. So perhaps should we add another function with the appropriate return > values; perhaps signed_remainder()? > > Notionally, it might work like this: > > global function signed_remainder(object a,object b) > integer atom_a,atom_b > atom c > > if find(b,{{},0.0} then > return {} -- not a valid 2nd argument > -- crash("Invalid 2nd argument to remainder()") > end if > atom_a=atom(a) > atom_b=atom(b) > if atom_a!=atom_b then > if atom_a then -- atom,sequence > for i=1 to length(b) do > b[i]=signed_remainder(a,b[i]) > end for > return b > else -- sequence,atom > for i=1 to length(a) do > a[i]=signed_remainder(a[i],b) > end for > return a > end if > elsif atom_a=0 then -- two sequences > if length(a)!=length(b) then > return {} -- let caller handle the mismatch > -- crash("Sequence lengths don't match") > else > for i=1 to length(a) do > a[i]=signed_remainder(a[i],b[i]) > end for > return a > end if > else -- two atoms > c=remainder(a,b) -- smallest magnitude and sign of a > if a<0!=b<0 then > return c+b > else > return c > end if > end function > > > It will be probably better implemented as a builtin if there is a corresponding > C stdlib function with the desired behaviour. If only to take advantage of the > sequence extension mechanism binary_op() in be_runtime.c provides. > > CChris -= B E G I N =- X-EUFORUM: 20368 Date: 2008 May 4 15:17 From: Jeremy Cowgar Subject: Re: locale support? I was originally thinking of providing a 100% euphoria solution, however, there are a lot of locales! So, I started in Linux, wrapped setlocale, strfmon and strftime. This gives us complete locale support in linux. You can use *any* locale that the user has installed. It'll format dates, times, currency and numbers according to that locale: include locale.e as l include datetime.e as d d:datetime now now = d:now() l:set("en_US") printf(1, "%s, %s, %s\n", { l:datetime("%A, %B %d %Y", now), l:money(10928.2), l:number(1029.35)}) Output is: Sunday, May 4 2008, $10,928.20, 1,029.35 You can set any locale and the date language will change, the currency symbol, the thousands and decimal point, etc... The final There are two more things to do: 1. make it work in Windows, see: http://www.openeuphoria.org/EUforum/m20366.html 2. Message localization. My ideas here are to provide .ini files (cross-platform) to provide localization files: data/en_US.ini data/en_CA.ini etc... HELLO=Hello WORLD=World GREETING=%s, %s! ERROR=Error: %i %s ERR_FILE_OPEN=%s could not be opened include locale.e as l l:set({"en_US", "data"}) puts(1, l:tr("$GREETING", {l:w("HELLO"), l:w("WORLD")})) puts(1, l:tr("$GREETING", {l:w("HELLO"), "John"})) puts(1, l:tr("$ERROR", {10, l:w("ERR_FILE_OPEN"), filename})) Since you use the tr and w functions often, they are tiny. tr = translate, w = word or lookup word. Anyway that's where I am at. Any thoughts? -- Jeremy Cowgar http://jeremy.cowgar.com -= B E G I N =- X-EUFORUM: 20369 Date: 2008 May 4 15:57 From: Jules Subject: ed problem ed on Linux crashes with this error message when I try to save a file in DOS format: "attempt to move cursor off the screen to line 1, column 89" Normally I get asked whether I want to save the file in DOS or Linux format, but for some reason this prompt is being bypassed. Can anyone help? Thanks. -= B E G I N =- X-EUFORUM: 20370 Date: 2008 May 4 16:06 From: jacques deschênes Subject: Re: remainder() is not right In fact remainder(x,y) means q*y+r=x so remainder(-27,3600)= (-27) is ok as 0*3600+(-27)=(-27) remainder(-3627,3600)=(-27) is ok as -1*3600+(-27)=(-3627) remainder(-3627,-3600) = -27 is ok as 1*(-3600)+(-27)=(-3627) remainder(27,-3600) = 27 is ok as 0*3600+ 27 = 27 Jacques Deschênes CChris wrote: > > > The remainder of x by y, which remainder() is supposed to return, is the number > with the smallest magnitude and the sign of y such that, if we call it z, x-z > is a multiple of y. > > But remainder() has a quirkier response. For instance: > ?remainder(-27,3600) -- -27, instead of 3573 > ?remainder(-3627,3600) -- ditto > ?remainder(-3627,-3600) -- -27 is correct here > ?remainder(27,-3600) -- 27, instead of -3573 > > Changing remainder()'s behaviour will break any code that works around this > behaviour. So perhaps should we add another function with the appropriate return > values; perhaps signed_remainder()? > > Notionally, it might work like this: > > global function signed_remainder(object a,object b) > integer atom_a,atom_b > atom c > > if find(b,{{},0.0} then > return {} -- not a valid 2nd argument > -- crash("Invalid 2nd argument to remainder()") > end if > atom_a=atom(a) > atom_b=atom(b) > if atom_a!=atom_b then > if atom_a then -- atom,sequence > for i=1 to length(b) do > b[i]=signed_remainder(a,b[i]) > end for > return b > else -- sequence,atom > for i=1 to length(a) do > a[i]=signed_remainder(a[i],b) > end for > return a > end if > elsif atom_a=0 then -- two sequences > if length(a)!=length(b) then > return {} -- let caller handle the mismatch > -- crash("Sequence lengths don't match") > else > for i=1 to length(a) do > a[i]=signed_remainder(a[i],b[i]) > end for > return a > end if > else -- two atoms > c=remainde