1. Rob?
- Posted by Vincent <darkvincentdude at yahoo.com> Feb 08, 2006
- 501 views
- Last edited Feb 09, 2006
Robert Craig wrote: > > > 1. Show me an actual example where you or someone else has > run into this "problem" in real life. Explain why in the first > decade of Euphoria, *no one* ever reported this "problem". > Explain why I should delay 100 other important features and bug > fixes, that people actually want, to address this possible "problem". > > 2. Give me a simple, totally reliable solution, coded in Euphoria, > that works on all platforms, with no ill side effects and does > not add *180* lines of code to the scanner. You say you will > do the long-term maintenance, but you've "quit" Euphoria twice > in just the past year. > > 3. Give me something I can write in the Euphoria language definition > that does not read "if you change the size of a comment in a > source file by one byte, your program's behavior could > change drastically". > > 4. It is bad netiquette to quote private e-mails on public > forums without the other party's permission. It does not > encourage the other party to exchange private e-mails with you > in the future. > > Regards, > Rob Craig > Rapid Deployment Software > <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a> So now that I've answered all those for you, you're just going to ignore me? That isn't very fair. I think I deserve a reply. If I was in your position I certainly wouldn't ignore a paying customer. Regards, Vincent P.S: What ever happened to the customer always being right?
2. Re: Rob?
- Posted by Robert Craig <rds at RapidEuphoria.com> Feb 09, 2006
- 472 views
Vincent wrote: > Robert Craig wrote: > > 1. Show me an actual example where you or someone else has > > run into this "problem" in real life. Explain why in the first > > decade of Euphoria, *no one* ever reported this "problem". > > Explain why I should delay 100 other important features and bug > > fixes, that people actually want, to address this possible "problem". > > > > 2. Give me a simple, totally reliable solution, coded in Euphoria, > > that works on all platforms, with no ill side effects and does > > not add *180* lines of code to the scanner. You say you will > > do the long-term maintenance, but you've "quit" Euphoria twice > > in just the past year. > > > > 3. Give me something I can write in the Euphoria language definition > > that does not read "if you change the size of a comment in a > > source file by one byte, your program's behavior could > > change drastically". > > > > 4. It is bad netiquette to quote private e-mails on public > > forums without the other party's permission. It does not > > encourage the other party to exchange private e-mails with you > > in the future. > > > So now that I've answered all those for you, you're just going to ignore me? > That isn't very fair. I think I deserve a reply. If I was in your position I > certainly wouldn't ignore a paying customer. > > Regards, > Vincent > > P.S: What ever happened to the customer always being right? I think you're getting a bit paranoid. I'm not ignoring you. It's just that I sometimes have to leave my computer to sleep, eat, or go out and buy food. I also have to serve many other customers. Customers who disagree with you. Can all customers be right? I'm also working hard on the multitasking feature, which I've now completed except for packaging the files and uploading them. Both the interpreter and translator now work fine with multitasking on DOS (both Watcom and DJGPP), Windows (Watcom, Borland, Lcc), Linux and FreeBSD. I also have example programs that use multitasking on all platforms. I'm building the Linux executables on a newer version of Linux, so maybe some things will work better for some people. I'll grant you that you've answered 1 and 4, (though the only person you referred to in 1 found a workaround, and is "not demanding" a change to the language). However I don't think you've provided a solution that answers both 2 & 3. You've also mentioned that your 180-line solution adds 10% to load time. I find this hard to believe, but if it's true, I can't believe that you would want that. You've been complaining with great passion about the load time issue, but now you're willing to throw 10% out the window, as long as the time is spent in your code handling a possible problem that does not affect 99% of all programs? Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
3. Re: Rob?
- Posted by Jason Gade <jaygade at yahoo.com> Feb 09, 2006
- 479 views
Robert Craig wrote: > > Vincent wrote: > > Robert Craig wrote: > > > 1. Show me an actual example where you or someone else has > > > run into this "problem" in real life. Explain why in the first > > > decade of Euphoria, *no one* ever reported this "problem". > > > Explain why I should delay 100 other important features and bug > > > fixes, that people actually want, to address this possible "problem". > > > > > > 2. Give me a simple, totally reliable solution, coded in Euphoria, > > > that works on all platforms, with no ill side effects and does > > > not add *180* lines of code to the scanner. You say you will > > > do the long-term maintenance, but you've "quit" Euphoria twice > > > in just the past year. > > > > > > 3. Give me something I can write in the Euphoria language definition > > > that does not read "if you change the size of a comment in a > > > source file by one byte, your program's behavior could > > > change drastically". > > > > > > 4. It is bad netiquette to quote private e-mails on public > > > forums without the other party's permission. It does not > > > encourage the other party to exchange private e-mails with you > > > in the future. > > > > > > So now that I've answered all those for you, you're just going to ignore me? > > That isn't very fair. I think I deserve a reply. If I was in your position I > > certainly wouldn't ignore a paying customer. > > > > Regards, > > Vincent > > > > P.S: What ever happened to the customer always being right? > > I think you're getting a bit paranoid. > I'm not ignoring you. It's just that I sometimes > have to leave my computer to sleep, eat, or go out and buy food. > I also have to serve many other customers. Customers who > disagree with you. Can all customers be right? > > I'm also working hard on the multitasking feature, which I've now > completed except for packaging the files and uploading them. > Both the interpreter and translator now work fine with multitasking > on DOS (both Watcom and DJGPP), Windows (Watcom, Borland, Lcc), > Linux and FreeBSD. I also have example programs that use multitasking > on all platforms. I'm building the Linux executables on a newer > version of Linux, so maybe some things will work better > for some people. WooHoo! Looking forward to this. > I'll grant you that you've answered 1 and 4, (though > the only person you referred to in 1 found a workaround, > and is "not demanding" a change to the language). > However I don't think you've provided a solution that > answers both 2 & 3. 2. Just compare the include string. If it is the same, then it is the same file. If it is not (different path) then it is not. Whether or not the file is the same, if global symbols conflict then it is an error and the include either needs to be namespaced or fixed. Local symbols are still unique. Again, this is just aesthetics on my part and definitely not extensive experience in programming language design. It seems to be pretty easy to change. 3. Deprecated by #2 above. > You've also mentioned that your 180-line solution > adds 10% to load time. I find this hard to believe, > but if it's true, I can't believe that you would want that. > You've been complaining with great passion about the > load time issue, but now you're willing to throw 10% > out the window, as long as the time is spent in your > code handling a possible problem that does not affect > 99% of all programs? > > Regards, > Rob Craig > Rapid Deployment Software > <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a> So, when can I start bugging you to support mingw (basically a Windows version of gcc) and let routine_id to have forward referencing? PS Seriously, you support DJGPP and gcc already, how hard would it be to support mingw? It's just another flavor. Maybe drop lcc? I know it's hard to support many different compilers but I'm not sure how different mingw is from gcc. I'm sure there are differences between it and DJGPP. -- "Any programming problem can be solved by adding a level of indirection." --anonymous "Any performance problem can be solved by removing a level of indirection." --M. Haertel j.
4. Re: Rob?
- Posted by Kenneth Rhodes <ken_rhodes30436 at yahoo.com> Feb 09, 2006
- 478 views
> > Robert Craig wrote: > > > > I'm also working hard on the multitasking feature, which I've now > > completed except for packaging the files and uploading them. > > Both the interpreter and translator now work fine with multitasking > > on DOS (both Watcom and DJGPP), Windows (Watcom, Borland, Lcc), > > Linux and FreeBSD. I also have example programs that use multitasking > > on all platforms. > >I'm building the Linux executables on a newer > > version of Linux, so maybe some things will work better > > for some people. > > If you don't mind my asking... Specifically, which version of Linux and which version of ncurses will Euphoria 3.0 use? Looking forward to the new release! Ken Rhodes 100% MicroSoft Free SuSE Linux 10.0 No AddWare, SpyWare, or Viruses! Life is Good
5. Re: Rob?
- Posted by Jason Gade <jaygade at yahoo.com> Feb 09, 2006
- 497 views
Kenneth Rhodes wrote: > > > > Robert Craig wrote: > > > > > > > I'm also working hard on the multitasking feature, which I've now > > > completed except for packaging the files and uploading them. > > > Both the interpreter and translator now work fine with multitasking > > > on DOS (both Watcom and DJGPP), Windows (Watcom, Borland, Lcc), > > > Linux and FreeBSD. I also have example programs that use multitasking > > > on all platforms. > > > >I'm building the Linux executables on a newer > > > version of Linux, so maybe some things will work better > > > for some people. > > > > > If you don't mind my asking... > Specifically, which version of Linux and which version of ncurses > will Euphoria 3.0 use? Maybe I'm naive, but I think that my Amiga used to work this way: Open a shared library by name, check it's version. If version was less than some number then exit. Doesn't Linux have a link from a generic 'ncurses' library that points to the latest version installed? Then the program should do a version check (included with the library) and exit with a message saying it requires a certain version if it is not greater. -- "Any programming problem can be solved by adding a level of indirection." --anonymous "Any performance problem can be solved by removing a level of indirection." --M. Haertel j.
6. Re: Rob?
- Posted by D. Newhall <derek_newhall at yahoo.com> Feb 09, 2006
- 491 views
Jason Gade wrote: > > So, when can I start bugging you to support mingw (basically a Windows version > of gcc) and let routine_id > to have forward referencing? > > PS Seriously, you support DJGPP and gcc already, how hard would it be to > support > mingw? It's just another flavor. Maybe drop lcc? I know it's hard to support > many different compilers but I'm not sure how different mingw is from gcc. I'm > sure there are differences between it and DJGPP. Mingw could be nice but how about MS Visual C++? Yes, it's not standard, yes, Microsoft is evil, and yes, it costs money but MS VC++ is a very popular compiler and might get some Microsofties to buy the translator. The Euphoria Standard Library project : http://esl.sourceforge.net/ The Euphoria Standard Library mailing list : https://lists.sourceforge.net/lists/listinfo/esl-discussion
7. Re: Rob?
- Posted by D. Newhall <derek_newhall at yahoo.com> Feb 09, 2006
- 481 views
Robert Craig wrote: > > Vincent wrote: > > P.S: What ever happened to the customer always being right? > > I also have to serve many other customers. Customers who > disagree with you. Can all customers be right? Without really getting into this I will say that it is impossible to satisfy all users, some want goto, some want associated arrays, some want integrated GUIs, etc. however, I would think that thread safety would be more useful than multitasking (at least for my use) but either is a nice addition. Vincent's arguments reminded me of this quote I read: "The language user is usually right ... It is impossible to overestimate the value of the direct feedback from users that was available while REXX was being designed” - Mike F. Cowlishaw (the creator of REXX), “The REXX Language, a practical approach to programming”, Prentice Hall, ISBN 0-13-779067-8 I'm not officially agreeing nor disagreeing with it just posting it for arguments sake. The Euphoria Standard Library project : http://esl.sourceforge.net/ The Euphoria Standard Library mailing list : https://lists.sourceforge.net/lists/listinfo/esl-discussion
8. Re: Rob?
- Posted by Kenneth Rhodes <ken_rhodes30436 at yahoo.com> Feb 09, 2006
- 482 views
D. Newhall wrote: > > Robert Craig wrote: > > > > Vincent wrote: > > > P.S: What ever happened to the customer always being right? > > > > I also have to serve many other customers. Customers who > > disagree with you. Can all customers be right? > > Without really getting into this I will say that it is impossible to satisfy > all users, some want goto, some want associated arrays, some want integrated > GUIs, etc. however, I would think that thread safety would be more useful than > multitasking (at least for my use) but either is a nice addition. Ever hear of "Arrow's Impossibility Theorem"? http://en.wikipedia.org/wiki/Arrow's_impossibility_theorem "Arrow's theorem says that if the decision-making body has at least two members and at least three options to decide among, then it is impossible to design a social welfare function that satisfies all these conditions at once." I bet Rob has really grown to appreciate Rick Nelson's song, "Garden Party". Ken Rhodes 100% MicroSoft Free SuSE Linux 10.0 No AddWare, SpyWare, or Viruses! Life is Good
9. Re: Rob?
- Posted by Robert Craig <rds at RapidEuphoria.com> Feb 09, 2006
- 484 views
Kenneth Rhodes wrote: > If you don't mind my asking... > Specifically, which version of Linux and which version of ncurses > will Euphoria 3.0 use? At the moment, I'm using the version of Linux on the ListFilter machine, (Red Hat I think) but I might switch to my own machine that has Mandrake 10.0, especially if people report any problems. Both versions of Linux are fairly recent. I haven't tried to pin down the exact ncurses versions. I still plan to do a version without ncurses, for people who would prefer that. Previously I was using an old Red Hat 5.2 Linux (circa 1999). I figured it was safer to stick with an older "lowest-common-denominator" version, than accidentally use new features that not everyone has. We'll see. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
10. Re: Rob?
- Posted by Robert Craig <rds at RapidEuphoria.com> Feb 09, 2006
- 477 views
Jason Gade wrote: > > I'll grant you that you've answered 1 and 4, (though > > the only person you referred to in 1 found a workaround, > > and is "not demanding" a change to the language). > > However I don't think you've provided a solution that > > answers both 2 & 3. > > 2. Just compare the include string. If it is the same, then it is the same > file. > If it is not (different path) then it is not. Whether or not the file is the > same, if global symbols conflict then it is an error and the include either > needs to be namespaced or fixed. Local symbols are still unique. > > Again, this is just aesthetics on my part and definitely not extensive > experience > in programming language design. It seems to be pretty easy to change. Well, you have a very simple solution, but it's not the problem Vincent was trying to solve. It would also cause every existing Euphoria program that has two different representations of the path to the same file to break. e.g. include graphics.e and include \euphoria\include\graphics.e or include mylib.e and include .\mylib.e Coming from a C background, my bias is to avoid including things twice. If you look at a really large C program, you'll see that they've invented ugly methods of preventing the same file from being included twice. They define artificial symbols, and then check if the symbol has been defined, if so, #ifdef around the rest of the file, else include it, yada yada yada... If you do include something twice, you get an avalanche of error messages. Please let me put this issue aside for now, and move on to more interesting enhancements! > So, when can I start bugging you to support mingw (basically a Windows version > of gcc) and let routine_id > to have forward referencing? > > PS Seriously, you support DJGPP and gcc already, how hard would it be to > support > mingw? It's just another flavor. Maybe drop lcc? I know it's hard to support > many different compilers but I'm not sure how different mingw is from gcc. I'm > sure there are differences between it and DJGPP. What would you do with mingw that you can't do with Borland or Watcom? It would take me a month (initially) to support a new C compiler, and there are already three for Windows that you can pick from. Most users don't care about C. They just want to translate/compile/run. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
11. Re: Rob?
- Posted by Vincent <darkvincentdude at yahoo.com> Feb 09, 2006
- 464 views
Robert Craig wrote: > > I think you're getting a bit paranoid. > I'm not ignoring you. It's just that I sometimes > have to leave my computer to sleep, eat, or go out and buy food. > I also have to serve many other customers. Customers who > disagree with you. Can all customers be right? I don't think it so much a matter of them disagreeing with me as it is with you disagreeing with them. > I'm also working hard on the multitasking feature, which I've now > completed except for packaging the files and uploading them. > Both the interpreter and translator now work fine with multitasking > on DOS (both Watcom and DJGPP), Windows (Watcom, Borland, Lcc), > Linux and FreeBSD. I also have example programs that use multitasking > on all platforms. I'm building the Linux executables on a newer > version of Linux, so maybe some things will work better > for some people. Great, the beer is on me. > I'll grant you that you've answered 1 and 4, (though > the only person you referred to in 1 found a workaround, > and is "not demanding" a change to the language). > However I don't think you've provided a solution that > answers both 2 & 3. Ok... I've thought about dir() some more and concluded that you can use that instead? Let me explain... You could more or less do everything I mentioned with my second proposal, but instead of checking and storing for file sizes, check and store results of dir(f); where f means the current file name. So now in order for two or more files to be percieved as the same, the results of the current dir() and a stored dir() must be exactly the same. Example: { { {109,105,115,99,46,101}, -- file name {97}, -- attribute 7577, -- byte size 2006, -- year 1, -- month 11, -- day 15, -- hour 18, -- minute 4 -- second } } So in order for Euphoria to quitely ignore an include statement: Two or more different files will need to have the same exact names, attributes, and byte sizes. But it would also need to been modified the same exact year, month, day, hour, minute, and second! Heres another simplifed example showing this idea in action:
include file.e sequence a, b a = dir("C:\\EUPHORIA\\include\\misc.e") b = dir("C:\\EUPHORIA\\include\\machine.e") if equal(a, b) then puts(1, "The two files are most likely the same.\n") else puts(1, "Isn't that cute... but it's WROOONNNGGG!!\n") end if machine_proc(26, 0)
I think I like this one better than my 180 line solution. What do you think? This is just as simple as the file size solution but with an extremely higher degree of accuracy. > You've also mentioned that your 180-line solution > adds 10% to load time. I find this hard to believe, > but if it's true, I can't believe that you would want that. > You've been complaining with great passion about the > load time issue, but now you're willing to throw 10% > out the window, as long as the time is spent in your > code handling a possible problem that does not affect > 99% of all programs? Well 10% is virtually undetectable on anything less than the biggest Euphoria programs. Like I said, the difference with the biggest program I've tested was less than a half second. Check out my dir() idea above. > Regards, > Rob Craig > Rapid Deployment Software > <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a> Regards, Vincent
12. Re: Rob?
- Posted by Igor Kachan <kinz at peterlink.ru> Feb 09, 2006
- 485 views
Vincent wrote: > > Robert Craig wrote: > > > > I think you're getting a bit paranoid. > > I'm not ignoring you. It's just that I sometimes > > have to leave my computer to sleep, eat, or go out and buy food. > > I also have to serve many other customers. Customers who > > disagree with you. Can all customers be right? > > I don't think it so much a matter of them disagreeing with me > as it is with you disagreeing with them. Hi Vincent, I am sorry, but I am afraid that I'm strongly against your solution on so called "include problem" for the official EU. I have some not bad experience about including almost same libs into EU programs. There is ru_eu_12.zip package in the Archive. It is a bilingual English/Russian Euphoria. And it has bilingual versions of all the official EU libs. Sorry, but it is much more convenient way to have, say, 'misc.e' for the pure English standard lib and 'misc___r.e' for almost same, but bilingual, lib rather than, say, 'misc.e' and 'russian/misc.e'. Just try some real life concrete (specific) work about these identical file names of libs and you'll too see lots of confusions if these different libs have identical names. Now I have NO problems and confusions, Euphoria cares, and I'll never confuse my libs this way. *The long file and path names were introduced to give us a powerful tool for resolving any file name conflicts.* Just use for your new lib some new good name and don't worry be happy. First time when this so called "include problem" poped up, was Bensler's attempt to replace RDS standard libs with his own unknown libs of identical names. Nobody befor him tried that dubious trick against the official RDS stuff. [snip] > > I'll grant you that you've answered 1 and 4, (though > > the only person you referred to in 1 found a workaround, > > and is "not demanding" a change to the language). > > However I don't think you've provided a solution that > > answers both 2 & 3. > > Ok... I've thought about dir() some more and concluded that you can use that > instead? > > Let me explain... > > You could more or less do everything I mentioned with my second proposal, but > instead of checking and storing for file sizes, check and store results of > dir(f); > where f means the current file name. > > So now in order for two or more files to be percieved as the same, the results > of the current dir() and a stored dir() must be exactly the same. > > Example: > > { > { > {109,105,115,99,46,101}, -- file name > {97}, -- attribute > 7577, -- byte size > 2006, -- year > 1, -- month > 11, -- day > 15, -- hour > 18, -- minute > 4 -- second > } > } > > So in order for Euphoria to quitely ignore an include statement: Two or more > different files > will need to have the same exact names, attributes, and byte sizes. But it > would also need > to been modified the same exact year, month, day, hour, minute, and second! > > > Heres another simplifed example showing this idea in action: > }}} <eucode> > include file.e > > sequence a, b > > a = dir("C:\\EUPHORIA\\include\\misc.e") > b = dir("C:\\EUPHORIA\\include\\machine.e") > > if equal(a, b) then > puts(1, "The two files are most likely the same.\n") > else > puts(1, "Isn't that cute... but it's WROOONNNGGG!!\n") > end if > > machine_proc(26, 0) > </eucode> {{{ > > I think I like this one better than my 180 line solution. > What do you think? > > This is just as simple as the file size solution but with an extremely higher > degree of accuracy. I'm sorry, but all these look like A-bomb against a sparrow. Just renaming of a new file solves that 'problem'. Path name and file name are different things, who cares about file attributes? It is too large reading, if you want to learn these attributes too. Why you do not want to name some your new lib, say, as "Vincent's_New_Lib_on_SVGA_graphics_for_DOS_and_Windows_and_Linux.e"? Just name it so and I'll pay you my MicroDollars forever, (if it will work on my machine)! > Regards, > Vincent Good Luck! Regards, Igor Kachan kinz at peterlink.ru
13. Re: Rob?
- Posted by Vincent <darkvincentdude at yahoo.com> Feb 09, 2006
- 482 views
Igor Kachan wrote: > > Hi Vincent, Hi there > I am sorry, but I am afraid that I'm strongly against your > solution on so called "include problem" for the official EU. I already knew you were against it. > I have some not bad experience about including almost same libs > into EU programs. There is ru_eu_12.zip package in the Archive. > > It is a bilingual English/Russian Euphoria. And it has bilingual > versions of all the official EU libs. > > Sorry, but it is much more convenient way to have, say, > 'misc.e' for the pure English standard lib and 'misc___r.e' > for almost same, but bilingual, lib rather than, say, > 'misc.e' and 'russian/misc.e'. Is that how your operating system works? Just because two files might be named the same doesn't mean they are. Should they be treated like they are? Obviously you're not looking at the big picture and the major effects this problem could bring down the road. > Just try some real life concrete (specific) work about these > identical file names of libs and you'll too see lots of > confusions if these different libs have identical names. It creates lots of confusion when your programs and/or libraries fail to work because of this issue. Just because it isn't a big deal now doesn't mean it shouldn't be fixed... after all the solutions are very simple. > Now I have NO problems and confusions, Euphoria cares, > and I'll never confuse my libs this way. > > *The long file and path names were introduced to give us > a powerful tool for resolving any file name conflicts.* > > Just use for your new lib some new good name and don't > worry be happy. Well it becomes a worry when somebody else uses your good name with their own programs and libraries. It becomes even more a problem when 10,000 or more do the same exact thing. That is very real a possability if Euphoria's popularity ever become significant. Worrying about this then is not a solution as it should have never existed to begin with. > First time when this so called "include problem" poped up, > was Bensler's attempt to replace RDS standard libs with > his own unknown libs of identical names. Chris Bensler is Anti-RDS. I support RDS and their buisness model (for the most part). > Nobody before him tried that dubious trick against the > official RDS stuff. > > [snip] > > I'm sorry, but all these look like A-bomb against a sparrow. > Just renaming of a new file solves that 'problem'. But how could that be a solution when that is the effect I'm trying to avoid? As for an A-bomb, I bet Iran's goal is to make one and devistate Israel with it; we can't let that happen. > Path name and file name are different things, who cares about > file attributes? It is too large reading, if you want to learn > these attributes too. > > Why you do not want to name some your new lib, say, as > "Vincent's_New_Lib_on_SVGA_graphics_for_DOS_and_Windows_and_Linux.e"? Heh... then we would have to rename it to make it shorter as it is way to long to type every time. > Just name it so and I'll pay you my MicroDollars forever, > (if it will work on my machine)! Huh? > Good Luck! > > Regards, > Igor Kachan > kinz at peterlink.ru Take care, Vincent
14. Re: Rob?
- Posted by Jason Gade <jaygade at yahoo.com> Feb 09, 2006
- 474 views
Robert Craig wrote: > > Jason Gade wrote: > > > I'll grant you that you've answered 1 and 4, (though > > > the only person you referred to in 1 found a workaround, > > > and is "not demanding" a change to the language). > > > However I don't think you've provided a solution that > > > answers both 2 & 3. > > > > 2. Just compare the include string. If it is the same, then it is the same > > file. > > If it is not (different path) then it is not. Whether or not the file is the > > same, if global symbols conflict then it is an error and the include either > > needs to be namespaced or fixed. Local symbols are still unique. > > > > Again, this is just aesthetics on my part and definitely not extensive > > experience > > in programming language design. It seems to be pretty easy to change. > > Well, you have a very simple solution, but it's not the problem > Vincent was trying to solve. It would also cause every existing > Euphoria program that has two different representations of the > path to the same file to break. e.g. include graphics.e > and include \euphoria\include\graphics.e or include mylib.e > and include .\mylib.e To use your own argument, how often does this happen unintentionally? Even when including multiple files (which should use namespaces for whatever files *they* include)? > Coming from a C background, my bias is to avoid including things > twice. If you look at a really large C program, you'll see that > they've invented ugly methods of preventing > the same file from being included twice. They define artificial symbols, > and then check if the symbol has been defined, if so, #ifdef around > the rest of the file, else include it, yada yada yada... > If you do include something twice, you get an avalanche of > error messages. > > Please let me put this issue aside for now, and move on to more > interesting enhancements! I'll drop it for now... I didn't expect to get anywhere with it anyway. I just think that it could make for easier modularity or object-type programming to be able to *intentionally* include a file more than once. Not exactly the same issue as Vincent is arguing but useful none the less. I think that Euphoria would behave *much* better than C in this respect. > > So, when can I start bugging you to support mingw (basically a Windows > > version > of gcc) and let routine_id</font></i> > > to have forward referencing? > > > > PS Seriously, you support DJGPP and gcc already, how hard would it be to > > support > > mingw? It's just another flavor. Maybe drop lcc? I know it's hard to support > > many different compilers but I'm not sure how different mingw is from gcc. > > I'm > > sure there are differences between it and DJGPP. > > What would you do with mingw that you can't do with Borland or Watcom? Have one less C compiler installed on my machine? I'm not translating anything right now anyway, I'll just have to bite the bullet when I need to because you don't support my favorite two comilers, mingw and digital mars. But there are more important things than supporting every C compiler known to humankind. > It would take me a month (initially) to support a new C compiler, > and there are already three for Windows that you can pick from. > Most users don't care about C. They just want to translate/compile/run. > > Regards, > Rob Craig > Rapid Deployment Software > <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a> Thanks for replying. -- "Any programming problem can be solved by adding a level of indirection." --anonymous "Any performance problem can be solved by removing a level of indirection." --M. Haertel j.
15. Re: Rob?
- Posted by Igor Kachan <kinz at peterlink.ru> Feb 09, 2006
- 473 views
- Last edited Feb 10, 2006
Vincent wrote: > > Igor Kachan wrote: > > [snip] > > [snip] > > > > I'm sorry, but all these look like A-bomb against a sparrow. > > Just renaming of a new file solves that 'problem'. > > But how could that be a solution when that is the effect I'm trying > to avoid? Just do remember that Euphoria just ignores double including and just do not include same file twice. Just avoid any struggle against this very useful feature. > As for an A-bomb, I bet Iran's goal is to make one and devistate > Israel with it; we can't let that happen. There is nothing to do with a real A-bomb, Iran, Israel, Chechen, Marks, Lenin, Stalin, Hitler and others on this list. The A-bombs and rokets are the only weapon against asteroids, comets etc and can be very useful for all us - Russians, Americans, Irani, Iraki, Chinese, Indian, Dutch, Hebrew, etc etc etc, for all living on this planet. But there is nothing to do with asteroids and comets here, sorry about OT. > > Path name and file name are different things, who cares about > > file attributes? It is too large reading, if you want to learn > > these attributes too. > > > > Why you do not want to name some your new lib, say, as > > "Vincent's_New_Lib_on_SVGA_graphics_for_DOS_and_Windows_and_Linux.e"? > > Heh... then we would have to rename it to make it shorter as it is way to long > to type every time. I'll be just happy to type this long name in my Euphoria programs. Then Euphoria code may be almost absolutelly platform independent. Do you see in EU docs : DOS, Windows, Linux? > > Just name it so and I'll pay you my MicroDollars forever, > > (if it will work on my machine)! > > Huh? Yes, I think that such a lib is one of the most needed. Make it and I'll pay you my MicroMoney with pleasure. Good Luck! Regards, Igor Kachan kinz at peterlink.ru
16. Re: Rob?
- Posted by Vincent <darkvincentdude at yahoo.com> Feb 10, 2006
- 490 views
Igor Kachan wrote: > > Just do remember that Euphoria just ignores double including > and just do not include same file twice. Yes that is what I want it to do. Some people want the ability to include the same file more than once. My idea will do exactly what you stated above if the files are *guaranteed* the same. Currently, Euphoria will make that assumption without any guarantee. > Just avoid any struggle against this very useful feature. This isn't a struggle you can avoid when encountered. However you can certainly make it a problem if want. > There is nothing to do with a real A-bomb, Iran, Israel, Chechen, > Marks, Lenin, Stalin, Hitler and others on this list. > > The A-bombs and rokets are the only weapon against asteroids, comets etc > and can be very useful for all us - Russians, Americans, Irani, Iraki, > Chinese, Indian, Dutch, Hebrew, etc etc etc, for all living on this planet. > > But there is nothing to do with asteroids and comets here, sorry about OT. <ot> Some people in this world are evil and/or corrupt and rather use those atomic bombs and missiles on their enemies. Iran for example supports global terrorism. Thinking that their efforts to resume the nuclear enrichment facilities for peaceful purposes is a big mistake. However I support the offer of Russia enriching the Uranium for Iran to allay suspicions. </ot> > I'll be just happy to type this long name in my Euphoria programs. > Then Euphoria code may be almost absolutelly platform independent. Well you will still be able to do that. > Do you see in EU docs : DOS, Windows, Linux? I studied the include system much more than I would have liked. > Yes, I think that such a lib is one of the most needed. > Make it and I'll pay you my MicroMoney with pleasure. What lib do you speak of? I'm not interested in the Micro-money but if you have an idea on a worthy project for me, I'd be glad to hear it. > Good Luck! > > Regards, > Igor Kachan > kinz at peterlink.ru I haven't given up on the issue yet, I'm going to try the dir() method and attempt to convince Rob to use it as it is so much better. If I lose after another long battle, maybe I'll rest my case or resume another battle. If he agrees to fix the problem (with or without my code) he will enjoy long term peace from my annoying complaints and a buisness transation for the v3.0 translator with a little something extra as a token of my appreciation. Regards, Vincent
17. Re: Rob?
- Posted by Robert Craig <rds at RapidEuphoria.com> Feb 10, 2006
- 494 views
Vincent wrote: > Ok... I've thought about dir() some more and concluded that you can use that > instead? > > Let me explain... > > You could more or less do everything I mentioned with my second proposal, but > instead of checking and storing for file sizes, check and store results of > dir(f); > where f means the current file name. > > So now in order for two or more files to be percieved as the same, the results > of the current dir() and a stored dir() must be exactly the same. > > Example: > > { > { > {109,105,115,99,46,101}, -- file name > {97}, -- attribute > 7577, -- byte size > 2006, -- year > 1, -- month > 11, -- day > 15, -- hour > 18, -- minute > 4 -- second > } > } > > So in order for Euphoria to quitely ignore an include statement: Two or more > different files > will need to have the same exact names, attributes, and byte sizes. But it > would also need > to been modified the same exact year, month, day, hour, minute, and second! > > > Heres another simplifed example showing this idea in action: > }}} <eucode> > include file.e > > sequence a, b > > a = dir("C:\\EUPHORIA\\include\\misc.e") > b = dir("C:\\EUPHORIA\\include\\machine.e") > > if equal(a, b) then > puts(1, "The two files are most likely the same.\n") > else > puts(1, "Isn't that cute... but it's WROOONNNGGG!!\n") > end if > > machine_proc(26, 0) > </eucode> {{{ > > I think I like this one better than my 180 line solution. > What do you think? > > This is just as simple as the file size solution but with an extremely higher > degree of accuracy. Yes, I thought about this method a few days ago, when I mentioned dir(), open() etc. in my private e-mail. The fact that it isn't perfect bothered me at the time, but I think I can accept it. Congratulations. The "extremely high degree of accuracy" is a bit misleading, since in some situations, copying a bunch of files will result in them all having the same time stamp. This is more likely on Linux/FreeBSD. In fact it's a little bit worrying to think that a program that's working could now fail just because it got copied to a new machine or a new directory. But this would be a very rare bug so I guess I can accept it. Also, in future I might add a couple of fields to the dir() result. On Linux/FreeBSD I could easily add the device number and inode number. The inode number is a unique number for each file on a device. There is no corresponding thing on DOS/Windows as far as I know, but maybe there's some extra info I could add. I guess I'll stick this into the code before the multitasking release, now that it's on my mind. That'll give me an excuse to delay the release and go watch a DVD. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
18. Re: Rob?
- Posted by Vincent <darkvincentdude at yahoo.com> Feb 10, 2006
- 514 views
Robert Craig wrote: > > Vincent wrote: > > Ok... I've thought about dir() some more and concluded that you can use that > > instead? > > > > Let me explain... > > > > You could more or less do everything I mentioned with my second proposal, > > but > > instead of checking and storing for file sizes, check and store results of > > dir(f); > > where f means the current file name. > > > > So now in order for two or more files to be percieved as the same, the > > results > > of the current dir() and a stored dir() must be exactly the same. > > > > Example: > > > > { > > { > > {109,105,115,99,46,101}, -- file name > > {97}, -- attribute > > 7577, -- byte size > > 2006, -- year > > 1, -- month > > 11, -- day > > 15, -- hour > > 18, -- minute > > 4 -- second > > } > > } > > > > So in order for Euphoria to quitely ignore an include statement: Two or more > different files</font></i> > > will need to have the same exact names, attributes, and byte sizes. But it > > would > also need</font></i> > > to been modified the same exact year, month, day, hour, minute, and second! > > > > > > Heres another simplifed example showing this idea in action: > > }}} <eucode> > > include file.e > > > > sequence a, b > > > > a = dir("C:\\EUPHORIA\\include\\misc.e") > > b = dir("C:\\EUPHORIA\\include\\machine.e") > > > > if equal(a, b) then > > puts(1, "The two files are most likely the same.\n") > > else > > puts(1, "Isn't that cute... but it's WROOONNNGGG!!\n") > > end if > > > > machine_proc(26, 0) > > </eucode> {{{ > > > > I think I like this one better than my 180 line solution. > > What do you think? > > > > This is just as simple as the file size solution but with an extremely > > higher > > degree of accuracy. > > Yes, I thought about this method a few days ago, when I mentioned > dir(), open() etc. in my private e-mail. The fact that it isn't perfect > bothered me at the time, but I think I can accept it. Congratulations. > > The "extremely high degree of accuracy" is a bit misleading, > since in some situations, copying a bunch of files will > result in them all having the same time stamp. This is more likely > on Linux/FreeBSD. In fact it's a little bit worrying to think that > a program that's working could now fail just because it got copied > to a new machine or a new directory. But this would be a very rare bug > so I guess I can accept it. Also, in future I might add a couple of fields to > the dir() result. On Linux/FreeBSD I could easily add the device number > and inode number. The inode number is a unique number for each file > on a device. There is no corresponding thing on DOS/Windows as far > as I know, but maybe there's some extra info I could add. > > I guess I'll stick this into the code before the multitasking release, > now that it's on my mind. That'll give me an excuse to delay the release > and go watch a DVD. > > Regards, > Rob Craig > Rapid Deployment Software > <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a> Thank you! That makes me so happy to hear! I didn't think about the time stamps changing when files where copied, but even if that happens, the file name, attributes, and byte size will still all have to be the same for them to be ignored. Besides any modifications you make towards the files afterwords will make the system regain its full accuracy. In the future when you implement additional fields into dir(), that will make the accuracy even higher. This fix alone is good enough for me to pay for the v3.0 translator upgrade. I think you have made the right decision for everyone here (including Igor) and for the future success of this language. Cheers, Vincent
19. Re: Rob?
- Posted by Jason Gade <jaygade at yahoo.com> Feb 10, 2006
- 497 views
Vincent wrote: > > Robert Craig wrote: > > > > Vincent wrote: > > > Ok... I've thought about dir() some more and concluded that you can use > > > that > > > instead? <snip> > > Yes, I thought about this method a few days ago, when I mentioned > > dir(), open() etc. in my private e-mail. The fact that it isn't perfect > > bothered me at the time, but I think I can accept it. Congratulations. > > <snip> > Thank you! That makes me so happy to hear! I didn't think about the time > stamps > changing when files where copied, but even if that happens, the file name, > attributes, > and byte size will still all have to be the same for them to be ignored. > Besides > any modifications you make towards the files afterwords will make the system > regain its full accuracy. In the future when you implement additional fields > into dir(), that will make the accuracy even higher. > > This fix alone is good enough for me to pay for the v3.0 translator upgrade. > I think you have made the right decision for everyone here (including Igor) > and for the future success of this language. > > > Cheers, > Vincent SCOOOOORE! Vincent! -- "Any programming problem can be solved by adding a level of indirection." --anonymous "Any performance problem can be solved by removing a level of indirection." --M. Haertel j.
20. Re: Rob?
- Posted by Igor Kachan <kinz at peterlink.ru> Feb 10, 2006
- 483 views
Jason Gade wrote: > > Vincent wrote: > > > > Robert Craig wrote: > > > > > > Vincent wrote: > <snip> [snip] > > Thank you! That makes me so happy to hear! I didn't think about the time > > stamps > > changing when files where copied, but even if that happens, the file name, > > attributes, > > and byte size will still all have to be the same for them to be ignored. > > Besides > > any modifications you make towards the files afterwords will make the system > > regain its full accuracy. In the future when you implement additional fields > > into dir(), that will make the accuracy even higher. > > > > This fix alone is good enough for me to pay for the v3.0 translator upgrade. > > I think you have made the right decision for everyone here (including Igor) > > and for the future success of this language. > > > > > > Cheers, > > Vincent > > SCOOOOORE! Vincent! > SCOOOOORE! Vincent! Good Luck! Regards, Igor Kachan kinz at peterlink.ru
21. Re: Rob?
- Posted by Igor Kachan <kinz at peterlink.ru> Feb 10, 2006
- 498 views
Vincent wrote: > > Igor Kachan wrote: > > > > I'll be just happy to type this long name in my Euphoria programs. > > Then Euphoria code may be almost absolutelly platform independent. > > Well you will still be able to do that. What that? Type long name? But I'll be happy *to type some very specific long name*, namely that one you have omitted here. > > Do you see in EU docs : DOS, Windows, Linux? > > I studied the include system much more than I would have liked. Ok, but did you notice many platform specific graphics, sound and mouse procedures and functions? These procedures and functions work nice on DOS32, but they can not work on WIN32, Linux and FreeBSD. EU programmer needs to learn Windows and *nix API to just put a pixel on the screen with exw.exe and exu interpreters. So, Euphoria needs some new_graphics.e library to make simple graphics operations in full screen mode under Windows or Linux/FreeBSD control, same as under DOS32 control. There are a few such libs in the Archive, but they wrap Allegro or SVGA, and so they are very version specific. > > Yes, I think that such a lib is one of the most needed. > > Make it and I'll pay you my MicroMoney with pleasure. > > What lib do you speak of? I'm not interested in the Micro-money but if you > have > an idea on a worthy project for me, I'd be glad to hear it. A lib which gives simple standard DOS32 SVGA graphics on Windows and Linux/FreeBSD. Do you see this problem? DOS, WIN and LNX Euphorias are too different on this part now because of very different graphics. I think, it is a very good task, just for you, Vincent. [snip] Regards, Igor Kachan kinz at peterlink.ru
22. Re: Rob?
- Posted by Vincent <darkvincentdude at yahoo.com> Feb 10, 2006
- 512 views
Igor Kachan wrote: > What that? Type long name? > But I'll be happy *to type some very specific long name*, > namely that one you have omitted here. You will still be able to do for example: "the_cow_jumped_over_the_moon.e", etc. > Ok, but did you notice many platform specific graphics, sound and > mouse procedures and functions? These procedures and functions work > nice on DOS32, but they can not work on WIN32, Linux and FreeBSD. > EU programmer needs to learn Windows and *nix API to just put a pixel > on the screen with exw.exe and exu interpreters. > So, Euphoria needs some new_graphics.e library to make simple graphics > operations in full screen mode under Windows or Linux/FreeBSD control, > same as under DOS32 control. > There are a few such libs in the Archive, but they wrap Allegro or > SVGA, and so they are very version specific. > A lib which gives simple standard DOS32 SVGA graphics on Windows and > Linux/FreeBSD. > Do you see this problem? DOS, WIN and LNX Euphorias are too different > on this part now because of very different graphics. > I think, it is a very good task, just for you, Vincent. OK... I see what your saying. Maybe I'll look into it later and check out the other libraries for ideas. It seems to me that there isn't any simple solution to cross-platform SVGA pixel graphics? > Regards, > Igor Kachan > kinz at peterlink.ru Regards, Vincent
23. Re: Rob?
- Posted by Igor Kachan <kinz at peterlink.ru> Feb 10, 2006
- 485 views
- Last edited Feb 11, 2006
Vincent wrote: > Igor Kachan wrote: [snip] > > A lib which gives simple standard DOS32 SVGA graphics on Windows and > > Linux/FreeBSD. > > > Do you see this problem? DOS, WIN and LNX Euphorias are too different > > on this part now because of very different graphics. > > > I think, it is a very good task, just for you, Vincent. > > OK... I see what your saying. Maybe I'll look into it later and check out the > other libraries for ideas. It seems to me that there isn't any simple solution > to cross-platform SVGA pixel graphics? I do not know if there is a simple solution, I just hope it may be simple enought if it is based on some kernel functions. But task is complicated one, yes, I think. Ok to finish this thread? Good Luck! Regards, Igor Kachan kinz at peterlink.ru
24. Re: Rob?
- Posted by Chris Burch <chriscrylex at aol.com> Feb 10, 2006
- 480 views
- Last edited Feb 11, 2006
Vincent wrote: > > Igor Kachan wrote: > > > What that? Type long name? > > > But I'll be happy *to type some very specific long name*, > > namely that one you have omitted here. > > You will still be able to do for example: "the_cow_jumped_over_the_moon.e", > etc. > > > Ok, but did you notice many platform specific graphics, sound and > > mouse procedures and functions? These procedures and functions work > > nice on DOS32, but they can not work on WIN32, Linux and FreeBSD. > > > EU programmer needs to learn Windows and *nix API to just put a pixel > > on the screen with exw.exe and exu interpreters. > > > So, Euphoria needs some new_graphics.e library to make simple graphics > > operations in full screen mode under Windows or Linux/FreeBSD control, > > same as under DOS32 control. > > > There are a few such libs in the Archive, but they wrap Allegro or > > SVGA, and so they are very version specific. > > > A lib which gives simple standard DOS32 SVGA graphics on Windows and > > Linux/FreeBSD. > > > Do you see this problem? DOS, WIN and LNX Euphorias are too different > > on this part now because of very different graphics. > > > I think, it is a very good task, just for you, Vincent. > > OK... I see what your saying. Maybe I'll look into it later and check out the > other libraries for ideas. It seems to me that there isn't any simple solution > to cross-platform SVGA pixel graphics? > > > Regards, > > Igor Kachan > > kinz at peterlink.ru > > > Regards, > Vincent There is already an SVGA lib wrapper in the archives (incomplete). The big problem with SVGA in Linux is that the library requires you to be root to run it, or else its very difficult to get running as a user. You would be far better off wrapping allegro for linux (honest), and running that on the xwindowing system. Allegro is largely cross platform, and shouldn't be too difficult to make cross platform replacements for eu's pixel graphics system. Chris http://members.aol.com/chriscrylex/euphoria.htm http://uboard.proboards32.com/ http://members.aol.com/chriscrylex/EUSQLite/eusql.html
25. Re: Rob?
- Posted by Vincent <darkvincentdude at yahoo.com> Feb 10, 2006
- 480 views
- Last edited Feb 11, 2006
Chris Burch wrote: > There is already an SVGA lib wrapper in the archives (incomplete). The big > problem > with SVGA in Linux is that the library requires you to be root to run it, or > else its very difficult to get running as a user. You would be far better off > wrapping allegro for linux (honest), and running that on the xwindowing > system. > > Allegro is largely cross platform, and shouldn't be too difficult to make > cross > platform replacements for eu's pixel graphics system. > > Chris > Thanks for the information. It wouldn't replace Euphoria's internal pixel graphic routines. I or someone else would just submit a library to the archive or something. Regards, Vincent