1. OpenEuphoria's Strategy
- Posted by jimcbrown (admin) Jan 13, 2015
- 3293 views
Forked from Re: Try/Catch
Before coding, I believe that a mature strategy must be defined more clearly. Obligation to your own Strategy - is not a luxury.
Before that, we need a goal. I think the goal is pretty clear - maintain and improve the language.
OpenEuphoria.org welcom page:
"Euphoria is a powerful but easy-to-learn programming language. It has a simple syntax and structure with consistent rules, and is also easy to read.".
This is a very accurate description of the language.
RapidEuphoria.com welcome page:
"Euphoria programming language, Simpler then Basic, More Powerful then C++".
This is a marketing catch-phrase - one of many that RDS used - and it's not even true. No version of Euphoria was ever more powerful than C++.
Perhaps it was simpler than Basic in the sense that it lacked certain features like builtin access to I/O ports (for the DOS version) or the lack of exception handling (which Basic had in the form of ON ERROR CONTINUE) or flow control (e.g. GOTO). I'm not sure that this was such a good thing.
Once you abandon your own obligation and belief, nobody else will take you seriously any more, and won't rely on your product any more.
What is written on RapidEuphoria.com represents the beliefs of two people - Rob Craig and Junko Muira. It was never binding on the rest of us.
If you really believe that RDS's vision was better, that's fine. You're free to go back and start maintaining an earlier version of the source, without all the changes in 4.0 and later. Others have announced that they'd do this, and I kind of wish they had succeeded - but the fact that they've never publiclyproduced anything shows that there isn't a lot of interest in going back.
While others, as Microsoft, may abandon their own obligations whenever they wish to, since they dominate the market by money, Euphoria simply can't; - doing so, might be the beginning-of-the-end of Euphoria.
I've seen it happening in the real world to entire companies. They started their way with very clear statements and promises for certain qualities - and after many years they had to give up their dream (to close), because they gave up their obligations to themselves and to their customers (slowly, invisibly, but surely).
None of this is applicable to us since there's no money involved, and no binding contracts.
2. Re: OpenEuphoria's Strategy
- Posted by Shian_Lee Jan 13, 2015
- 3236 views
jimcbrown... I guess that you and I have a bad Karma... :)
While I truly respect you (without knowing much about you), it seems that we are really misunderstanding each other. Non of your answers are really getting to the point of what I try to say, honestly.
Personally I have no problem to program in Euphoria 3.1.1, C, or Java. It takes some time to read, learn, practice - but that's all (although I formally graduated only 6 years of elementary school, and that's all, it's still an IQ related subject).
I can't agree that Euphoria 3.1.1 is less then BASIC... I wish that I had Euphoria 3.1.1 when I had to program in QuickBasic or VBDOS - those programs could have been done in a month. Of course, I had to make sure that I create a decent COM port library. But that's fun. I've almost never ever used error handler in QuickBasic, and at least 1 of my big programs is celebrating now 23 years at active service (without any error handler).
I will leave the forum, so don't bother yourself with "strategy" please.
Thank you, and all the best.
3. Re: OpenEuphoria's Strategy
- Posted by jimcbrown (admin) Jan 13, 2015
- 3218 views
While I truly respect you (without knowing much about you), it seems that we are really misunderstanding each other. Non of your answers are really getting to the point of what I try to say, honestly.
I will leave the forum, so don't bother yourself with "strategy" please.
Thank you, and all the best.
A shame you couldn't express yourself more clearly, then.
I can't agree that Euphoria 3.1.1 is less then BASIC...
It's tricky, since there's so many versions of BASIC, some of which has some very different features. I still think it's self-evident that Euphoria 3.1.1 has fewer features, however.
4. Re: OpenEuphoria's Strategy
- Posted by dcuny Jan 13, 2015
- 3216 views
I will leave the forum, so don't bother yourself with "strategy" please.
While people(myself include) may not agree with everything you've written, it is being noted and taken seriously.
I think the Euphoria forum will be poorer with your absence.
- David
5. Re: OpenEuphoria's Strategy
- Posted by GreenEuphorian Jan 17, 2015
- 3179 views
I will leave the forum, so don't bother yourself with "strategy" please.
While people(myself include) may not agree with everything you've written, it is being noted and taken seriously.
I think the Euphoria forum will be poorer with your absence.
- David
I agree. Staying on and trying to change things is the thing to do.
6. Re: OpenEuphoria's Strategy
- Posted by Shian_Lee Jan 31, 2015
- 3138 views
Rob Craig is missing here - not me.
Rob Craig could explain what Strategy is all about.
Rob Craig was against 'goto' since he has a Strategy. That is the only reason that I was interested in using Euphoria.
Without a clear strategy Euphoria is just another programming language, and I don't see why should anyone prefer it over the other intellectual garbage bins (such as Java, Visual-Basic, PHP, etc).
7. Re: OpenEuphoria's Strategy
- Posted by GreenEuphorian Feb 01, 2015
- 2989 views
Rob Craig is missing here - not me.
Rob Craig could explain what Strategy is all about.
Rob Craig was against 'goto' since he has a Strategy. That is the only reason that I was interested in using Euphoria.
Without a clear strategy Euphoria is just another programming language, and I don't see why should anyone prefer it over the other intellectual garbage bins (such as Java, Visual-Basic, PHP, etc).
Ok, so what strategy do you suggest, Shian? (apart from eliminating goto)
8. Re: OpenEuphoria's Strategy
- Posted by Shian_Lee Feb 01, 2015
- 2959 views
No need for more (OOP, struct, etc) - add many Euphoria standard libraries including GUI libraries and wrappers, focus on marketing with IDE, tutorials, examples, documentation.
Finish the error handling issue, 64-bits, bugs and tickets - and find the place for Euphoria in the real world.
9. Re: OpenEuphoria's Strategy
- Posted by GreenEuphorian Feb 01, 2015
- 2956 views
[...] tutorials, examples, documentation.
I very much agree on this.
10. Re: OpenEuphoria's Strategy
- Posted by Shian_Lee Feb 01, 2015
- 2958 views
Life is not forever, and Euphoria is basically done - it's time to enjoy it, and let others enjoy it too.
11. Re: OpenEuphoria's Strategy
- Posted by Shian_Lee Feb 02, 2015
- 2946 views
US could not win the shameful Vietnam war, since big, massive, expensive and slow army - cannot win guerrilla troops on their own land.
Simple strategy mistake leaded to catastrophy - by arrogant headquarters which underestimated the "primitive barbarians".
Rob was creating a guerrilla force, powerful, efficient, small, fast, versatile and practical. Euphoria was never meant to become a heavy, slow and massive/expensive tool.
Euphria's real streangh will be lost as soon as it becomes massive. Right now Java is too massive to even calculate 1+1. That is the tragedy of any massive army.
Repls, pass by reference, - even enum or label, eval and such, are suitable for massive army. Euphoria simply don't need any of it.
OpenEuphria is getting less and less practical, similar to the entire computer generation.
Then go ahead, do what you wish. I offer you all some physical activity, some sport, some physical work to return back to Earth and see the beauty of God's creation (flowers, trees, fresh air). It may add some proportion to your thoughts.
With all the obvious respect.
12. Re: OpenEuphoria's Strategy
- Posted by kinzz Feb 02, 2015
- 2942 views
US could not win the shameful Vietnam war, since big, massive, expensive and slow army - cannot win guerrilla troops on their own land.
Simple strategy mistake leaded to catastrophy - by arrogant headquarters which underestimated the "primitive barbarians".
Rob was creating a guerrilla force, powerful, efficient, small, fast, versatile and practical. Euphoria was never meant to become a heavy, slow and massive/expensive tool.
Euphria's real streangh will be lost as soon as it becomes massive. Right now Java is too massive to even calculate 1+1. That is the tragedy of any massive army.
Repls, pass by reference, - even enum or label, eval and such, are suitable for massive army. Euphoria simply don't need any of it.
OpenEuphria is getting less and less practical, similar to the entire computer generation.
Then go ahead, do what you wish. I offer you all some physical activity, some sport, some physical work to return back to Earth and see the beauty of God's creation (flowers, trees, fresh air). It may add some proportion to your thoughts.
With all the obvious respect.
Absolutely! Just my own thoughts!
Best Regards to All!
Igor Kachan (aka kinz)
kinz
13. Re: OpenEuphoria's Strategy
- Posted by irv Feb 02, 2015
- 2905 views
People here seem to have forgotten the reason that there is an OpenEuphoria:
Computers, and the uses to which people put their computers, were growing rapidly, and Euphoria was growing, at best, at a 'glacial' pace.
It wouldn't run on any platform but DOS (with a passing but nearly unworkable flirtation with Windows). Eu was already out-of-date, since we were using Windows and the internet to request various 'modern' features.
Rob's idea was to let users write all the badly-needed extra stuff, but this didn't work very well. Some were impossible - such as getting Eu to run on Linux or Mac. Others were possible, but were done in different, non-compatible, and often incomplete, ways by various users. Some are just to massive for one user to handle.
That's why Rob released the source. Apparently, that's not working too well either, but at least there's some progress.
I'm puzzled by the posters here who seem to want Euphoria to be unusable on modern computers. I'm also puzzled why they bother to make the request, since as far as I know, Eu 2.1 is freely available. Download it, and then go dig up a 286 computer with 256 megs of memory to run it on. There's no need to force the rest of us to go retro.
14. Re: OpenEuphoria's Strategy
- Posted by Shian_Lee Feb 02, 2015
- 2886 views
Irv,
Nobody forgot anything.
I use LinuxMint 17, then how can I possibly forget?
But there are many ways to do the same thing, also on modern OS.
One may prefer OOP while one may prefer the more traditional way.
But, clear decision must be made. If all admins are sure about the current road map, then no more posts! Actually, since not much is clear anyways, then maybe it's better to leave. But not before saying - THANKS! To all of you.
15. Re: OpenEuphoria's Strategy
- Posted by kinzz Feb 03, 2015
- 2862 views
I'm puzzled by the posters here who seem to want Euphoria to be unusable on modern computers.
Hi Irv.
All versions of EU, from 1.0 to 3.*, are 100% usable on modern computers in DOSBox.
Just ex.exe, under Windows, FreeBSD, Fedora, Gentoo Linux, Mac OS X, OS/2, RISC OS, Debian, Solaris 10, BeOS plus Russian KolibriOS, Rosa Linux etc.
So, yours "who seem to want" is just absolutely impossible.
I'm also puzzled why they bother to make the request, since as far as I know, Eu 2.1 is freely available.
Yes, but any version of EU is freely available now and can work with programs of The RDS Archive.
Download it, and then go dig up a 286 computer with 256 megs of memory to run it on.
He-he, Irv, EU works on 386 and up with 640k and up. It doesn't work on 286.
There's no need to force the rest of us to go retro.
But who "forces the rest of us to go retro"?
My main PC now is Packard Bell monoblock oneTwo L5351, AMD Athlon(tm) II X4 605e 2.30GHz, 8.00Gb RAM, 500Gb HDD, 1920x1080 touchscreen, Windows 7 max + Windows XP Pro + DOSBox 0.74, Rosa Linux + DOSBox 0.74.
Is it "retro" or is it too bad?
But I have my old good mainframe 386DX 25MGz with 8.00Mb RAM too, and it works ok.
Best Regards!
Igor Kachan
kinz
16. Re: OpenEuphoria's Strategy
- Posted by kinzz Feb 03, 2015
- 2828 views
Just ex.exe, under Windows, FreeBSD, Fedora, Gentoo Linux, Mac OS X, OS/2, RISC OS, Debian, Solaris 10, BeOS plus Russian KolibriOS, Rosa Linux etc.
Hey, Irv, do you see one of Rob's guerrilla paratroopers now?
It is ex.exe of EU, abandoned by OE.
Old good ex.exe, without enum etc. 
Best Regards!
Igor Kachan
kinz
17. Re: OpenEuphoria's Strategy
- Posted by BRyan Feb 03, 2015
- 2805 views
Hey Igor:
I have not given up on eu 3.1.1
ex.exe still works great !
Bernie
18. Re: OpenEuphoria's Strategy
- Posted by Spock Feb 03, 2015
- 2815 views
People here seem to have forgotten the reason that there is an OpenEuphoria:
Computers, and the uses to which people put their computers, were growing rapidly, and Euphoria was growing, at best, at a 'glacial' pace.
It wouldn't run on any platform but DOS (with a passing but nearly unworkable flirtation with Windows). Eu was already out-of-date, since we were using Windows and the internet to request various 'modern' features.
Rob's idea was to let users write all the badly-needed extra stuff, but this didn't work very well. Some were impossible - such as getting Eu to run on Linux or Mac. Others were possible, but were done in different, non-compatible, and often incomplete, ways by various users. Some are just to massive for one user to handle.
That's why Rob released the source. Apparently, that's not working too well either, but at least there's some progress.
I'm puzzled by the posters here who seem to want Euphoria to be unusable on modern computers. I'm also puzzled why they bother to make the request, since as far as I know, Eu 2.1 is freely available. Download it, and then go dig up a 286 computer with 256 megs of memory to run it on. There's no need to force the rest of us to go retro.
Most of this diatribe is just nonsense. Even a mere glance at the news page page quickly exposes most of the false and misleading statements.
The slur about "posters here who seem to want Euphoria to be unusable on modern computers" is not only false but a clear violation of the Code of Conduct.
Spock
19. Re: OpenEuphoria's Strategy
- Posted by jimcbrown (admin) Feb 03, 2015
- 2787 views
Most of this diatribe is just nonsense. Even a mere glance at the news page page quickly exposes most of the false and misleading statements.
irv is talking about the pre-1995 days, predating the oldest new on that page. I believe what he said was true, for the earliest versions of Euphoria.
The slur about "posters here who seem to want Euphoria to be unusable on modern computers" is not only false but a clear violation of the Code of Conduct.
No, it isn't. As a third party looking in, I think that the inference is reasonable - and in any case, irv only says it seems to be this way and admits that it's puzzling. Which is to say that irv implies that it's possible he might be wrong. irv isn't forcibly attributing a view to a specific user that the user does not hold, but generically stating that some (unspecified) individuals appear to hold these views.... This is appropriate and not disrespectful to anyone.
Even if irv were forcibly attributing obviously false views to users who clearly didn't hold them, this isn't a CodeOfConduct violation unless the user that irv is attacking can be reasonably identified.
20. Re: OpenEuphoria's Strategy
- Posted by dcuny Feb 03, 2015
- 2752 views
Even if irv were forcibly attributing obviously false views to users who clearly didn't hold them, this isn't a CodeOfConduct violation unless the user that irv is attacking can be reasonably identified.
Ah, so if I say "There may be some lunk-headed Euphoria users who might for entirely unreasonable reasons consider the addition of Some_Random_Feature not to be the greatest thing since Donald Knuth, but I'd never be so unkind to describe such folk as pig-headed or obstinate.", then we're all good? 
- David
This weak attempt at humour really isn't aimed at anyone! I just couldn't resist the loophole! 
21. Re: OpenEuphoria's Strategy
- Posted by jimcbrown (admin) Feb 03, 2015
- 2756 views
This weak attempt at humour really isn't aimed at anyone! I just couldn't resist the loophole!
Yes, the loophole is real.
22. Re: OpenEuphoria's Strategy
- Posted by Spock Feb 03, 2015
- 2760 views
Most of this diatribe is just nonsense. Even a mere glance at the news page page quickly exposes most of the false and misleading statements.
irv is talking about the pre-1995 days, predating the oldest new on that page. I believe what he said was true, for the earliest versions of Euphoria.
The context of Irv's comment was clearly linked to "OpenEuphoria" and the releasing of the source (which was 2006). Any suggestion that OpenEuphoria emerged because of frustration at the slow pace of development etc pre-1995 is just ridiculous given that Eu 1.0 was only released in 1993!
The slur about "posters here who seem to want Euphoria to be unusable on modern computers" is not only false but a clear violation of the Code of Conduct.
No, it isn't. As a third party looking in, I think that the inference is reasonable - and in any case, irv only says it seems to be this way and admits that it's puzzling. Which is to say that irv implies that it's possible he might be wrong. irv isn't forcibly attributing a view to a specific user that the user does not hold, but generically stating that some (unspecified) individuals appear to hold these views.... This is appropriate and not disrespectful to anyone.
Even if irv were forcibly attributing obviously false views to users who clearly didn't hold them, this isn't a CodeOfConduct violation unless the user that irv is attacking can be reasonably identified.
If you can justify (as you have attempted to) the legitimacy of a comment like "posters here who seem to want Euphoria to be unusable on modern computers" then can I legitimately say "developers who seem to want to bastardise Euphoria and make it a hoary dog of a language" ?
Well, can I?
To some people such an inference might seem completely reasonable.
Spock
23. Re: OpenEuphoria's Strategy
- Posted by jimcbrown (admin) Feb 03, 2015
- 2756 views
Most of this diatribe is just nonsense. Even a mere glance at the news page page quickly exposes most of the false and misleading statements.
irv is talking about the pre-1995 days, predating the oldest new on that page. I believe what he said was true, for the earliest versions of Euphoria.
The context of Irv's comment was clearly linked to "OpenEuphoria" and the releasing of the source (which was 2006).
I disagree. I think the defining events were the release of 4.0.0 and the dropping of DOS support.
A lot of users unhappy at the direction 4.0 has gone seem quite happy with 3.1.1, which was open source and released by the dev team....
Any suggestion that OpenEuphoria emerged because of frustration at the slow pace of development etc pre-1995 is just ridiculous given that Eu 1.0 was only released in 1993!
Some allowance must be made for hyperbole.
The slur about "posters here who seem to want Euphoria to be unusable on modern computers" is not only false but a clear violation of the Code of Conduct.
No, it isn't. As a third party looking in, I think that the inference is reasonable - and in any case, irv only says it seems to be this way and admits that it's puzzling. Which is to say that irv implies that it's possible he might be wrong. irv isn't forcibly attributing a view to a specific user that the user does not hold, but generically stating that some (unspecified) individuals appear to hold these views.... This is appropriate and not disrespectful to anyone.
Even if irv were forcibly attributing obviously false views to users who clearly didn't hold them, this isn't a CodeOfConduct violation unless the user that irv is attacking can be reasonably identified.
If you can justify (as you have attempted to) the legitimacy of a comment like "posters here who seem to want Euphoria to be unusable on modern computers" then can I legitimately say "developers who seem to want to bastardise Euphoria and make it a hoary dog of a language" ?
Well, can I?
Short answer: yes, with some minor rewording: "there appear to be some developers out there who seem to want to bastardise Euphoria and make it a hoary dog of a language" ?
Long answer: no, because the phrasing is vague and can be interpreted two ways: some developers want to do X, or all developers want to do X. The second form clearly identifies the target to the point that we can name names. Since it's not clear which version is intended, a reasonable person can conclude that it was the second form that was meant.
To some people such an inference might seem completely reasonable.
Spock
I don't agree. I think there's a difference between feature-ism and trying to make things look like canines. I suppose some allowance must be made for hyperbole, however...
24. Re: OpenEuphoria's Strategy
- Posted by kinzz Feb 04, 2015
- 2764 views
Hey Igor:
I have not given up on eu 3.1.1
ex.exe still works great !
Bernie
Hi Bernie!
Glad to hear you, old good Bernie!
Try please these thingies:
http://www.private.peterlink.ru/kinz/3.2ru/ex_i.exe - ex.exe of 3.2ru EU
http://www.private.peterlink.ru/kinz/3.2ru/exw_i.exe - exw.exe of 3.2ru EU
http://www.private.peterlink.ru/kinz/3.2ru/exu_iz - exu of 3.2ru EU (bug in get_position())
These ones are bilingual pure EU interpreters, they work in English and Russian, have an unlimited alphabet for identifiers, alpha-1 stage.
Best Regards!
Igor Kachan
kinz
25. Re: OpenEuphoria's Strategy
- Posted by irv Feb 04, 2015
- 2706 views
When I said 'unusable on modern computers' - I meant unusuable in the same way that a model-t ford is 'unusable' on the autobahn.
Not that it cannot be done.
I think anyone trying to do either should expect some questions along the lines of "why do you want to do that?"
26. Re: OpenEuphoria's Strategy
- Posted by Shian_Lee Feb 04, 2015
- 2665 views
I think anyone trying to do either should expect some questions along the lines of "why do you want to do that?"
- Since we already have Java, C++, Python, ... and we don't need another version of the same methods. Java is enough.
- Since it's fun (don't you agree?). Euphoria is still fun compares to other languages.
- Since other languages don't let me do that.
- Since simple and beautiful interpreter is enough for almost anything I need - and if not... then I can use Java - or just create it in 10 minutes with some Visual tool.
- Since we love Euphoria and we want to keep it simple as it was.
- Since driving in a slow and old car - let us see and enjoy the sky and trees outside the window.
- Since we just love adventures.
- Since the others already did everything - then why we should try to copy their success or failure?
- Since we are realistic: I want to use Euphoria today - not in 15 years from now. (and without 10,000 unresolved tickets).
- Since simple is reliable.
I could go on and on. But honestly Irv, it's all about perspective. And I can surely understand your perspective - so please try to understand mine.
27. Re: OpenEuphoria's Strategy
- Posted by dcuny Feb 04, 2015
- 2637 views
- Since we already have Java, C++, Python, ... and we don't need another version of the same methods. Java is enough.
The first version of my application was written in Java. Using Eclipse is a real joy.
But... Many of my users would rather not have Java run on their machine. Some don't use Java because of security reasons. Others don't like being continually nagged about Java wanting to upgrade, and others don't like the was the Java installer tries to trick them into installing other applications onto their machines.
So Java turned out not to be a viable option.
I then ported the code to C. The Microsoft IDE is very nice, but it's still compiled code. When I started getting "random" errors, I knew there was a memory leak of some sort. Had I been using Java, it would have caught it immediately. Even with the tools checking for bad memory access, as long as the application is accessing memory that's been malloc'ed, there's no error.
Tracking down that sort of error in C is a real pain.
So, now I'm looking at Euphoria, because Java, C and Python aren't options.
- David
28. Re: OpenEuphoria's Strategy
- Posted by Shian_Lee Feb 04, 2015
- 2628 views
...So, now I'm looking at Euphoria, because Java, C and Python aren't options.
- David
David, we are both looking at Euphoria from more or less exactly the same reasons.
Where I live I see all the time army vehicle, very powerful one, which has also civilian version. The army version of this car could cross very tough land, since it is plain, simple, strong and has nothing but tyres and on/off switch... - The civilian version has radio, stereo, speakers, windows, mirror, GPS, place for coffee cup, ...
I'd prefer the army version of that vehicle. Many love the bloated and expensive civilian version.
29. Re: OpenEuphoria's Strategy
- Posted by jimcbrown (admin) Feb 04, 2015
- 2628 views
So, now I'm looking at Euphoria, because Java, C and Python aren't options.
Why isn't Python an option? You explained the other two, but omitted Python. Just curious.
30. Re: OpenEuphoria's Strategy
- Posted by dcuny Feb 04, 2015
- 2620 views
Why isn't Python an option? You explained the other two, but omitted Python. Just curious.
Ooops. I should have written Lua, not Python.
To be honest, I probably should be using Python.
But I figured it would probably be easier to port the code to Euphoria, since it would have less of a learning curve. I'd already gone through the suffering of porting the code to C, and didn't want to learn a new language.
Plus, the code needs to run reasonably fast. It's a voice synthesis program, and even in C was pretty slow. Euphoria gives the option to fall back to a compiled version. I figured that if Python turned out to be too slow, I'd pretty much be stuck, and have to port the program yet again.
- David
31. Re: OpenEuphoria's Strategy
- Posted by Spock Feb 04, 2015
- 2604 views
Why isn't Python an option? You explained the other two, but omitted Python. Just curious.
Ooops. I should have written Lua, not Python.
To be honest, I probably should be using Python.
But I figured it would probably be easier to port the code to Euphoria, since it would have less of a learning curve. I'd already gone through the suffering of porting the code to C, and didn't want to learn a new language.
Plus, the code needs to run reasonably fast. It's a voice synthesis program, and even in C was pretty slow. Euphoria gives the option to fall back to a compiled version. I figured that if Python turned out to be too slow, I'd pretty much be stuck, and have to port the program yet again.
- David
David,
There's bound to be some inner loop that is required to be as fast as possible. If the HL equivalent isn't too lengthy said inner loop could be written in ASM. Almost like Pete has done in Phix, I use ASM snippets in Orac. Since apparently C is not fast enough do you require MMX operations?
(I hope I won't be sorry I asked ..)
Spock
32. Re: OpenEuphoria's Strategy
- Posted by andi49 Feb 04, 2015
- 2613 views
Why isn't Python an option? You explained the other two, but omitted Python. Just curious.
Ooops. I should have written Lua, not Python.
To be honest, I probably should be using Python.
But I figured it would probably be easier to port the code to Euphoria, since it would have less of a learning curve. I'd already gone through the suffering of porting the code to C, and didn't want to learn a new language.
Plus, the code needs to run reasonably fast. It's a voice synthesis program, and even in C was pretty slow. Euphoria gives the option to fall back to a compiled version. I figured that if Python turned out to be too slow, I'd pretty much be stuck, and have to port the program yet again.
- David
I'am just curious why not Pascal? Or did you here about http://nim-lang.org/ (i mention this becouse it has some similaritys to Python and Pascal)
(btw i do not like this "Whitespace is significant in Python source code" if prefer "begin" and "end" like in Pascal (or Euphoria))
Andreas
33. Re: OpenEuphoria's Strategy
- Posted by GreenEuphorian Feb 04, 2015
- 2611 views
Or did you here about http://nim-lang.org/ (i mention this becouse it has some similaritys to Python and Pascal)
(btw i do not like this "Whitespace is significant in Python source code" if prefer "begin" and "end" like in Pascal (or Euphoria))
Andreas
Andreas, are you Nim's author? I noticed that his name is also Andreas. Maybe just a coincidence.
34. Re: OpenEuphoria's Strategy
- Posted by andi49 Feb 04, 2015
- 2604 views
Or did you here about http://nim-lang.org/ (i mention this becouse it has some similaritys to Python and Pascal)
(btw i do not like this "Whitespace is significant in Python source code" if prefer "begin" and "end" like in Pascal (or Euphoria))
Andreas
Andreas, are you Nim's author? I noticed that his name is also Andreas. Maybe just a coincidence.
Hahaha
I'am not playing in this league
I'am just a hobby programmer. We just share the same first name.
He is also German and he also visited a Univerity not far away where I live.
But that's all. I talked to him once on irc. The language has a lot influence from python and pascal.
35. Re: OpenEuphoria's Strategy
- Posted by andi49 Feb 04, 2015
- 2615 views
Or did you here about http://nim-lang.org/ (i mention this becouse it has some similaritys to Python and Pascal)
(btw i do not like this "Whitespace is significant in Python source code" if prefer "begin" and "end" like in Pascal (or Euphoria))
Andreas
Andreas, are you Nim's author? I noticed that his name is also Andreas. Maybe just a coincidence.
Hahaha
I'am not playing in this league
I'am just a hobby programmer. We just share the same first name.
He is also German and he also visited a Univerity not far away where I live.
But that's all. I talked to him once on irc. The language has a lot influence from python and pascal.
(BTW He told me that he always posted here with his realname 'Andreas Rumpf' and on IRC as 'Araq'.
not as 'Critic')
Andreas
36. Re: OpenEuphoria's Strategy
- Posted by dcuny Feb 04, 2015
- 2578 views
There's bound to be some inner loop that is required to be as fast as possible. If the HL equivalent isn't too lengthy said inner loop could be written in ASM. Almost like Pete has done in Phix, I use ASM snippets in Orac. Since apparently C is not fast enough do you require MMX operations?
I'd rather not resort to that. The output doesn't have to be real time, it just can't be too slow.
It was taking 184 seconds to render 55 seconds of audio yesterday.
So I ran the profile against it. It took several attempts, because I kept exceeding the profile limits.
I finally got it to work with:
with profile_time 50000000
Here's one place that had an obvious optimization:
-- filter sample atom out = sample*this[B0] + this[Z][1]*this[B1] + this[Z][2]*this[B2] - this[Z][3]*this[A1] - this[Z][4]*this[A2] -- shift history this[Z][4] = this[Z][3] this[Z][3] = out this[Z][2] = this[Z][1] this[Z][1] = sample
Indexing indexes is horrifically expensive in Euphoria. I replaced it with:
-- filter sample atom out = sample*this[B0] + this[Z1]*this[B1] + this[Z2]*this[B2] - this[Z3]*this[A1] - this[Z4]*this[A2] -- shift history this[Z4] = this[Z3] this[Z3] = out this[Z2] = this[Z1] this[Z1] = sample
and dropped the time to 42 seconds. I shaved another 8 seconds off by optimizing a few more operations.
I'll look at further optimizations later, but for now I've got more important things to fix.
- David
37. Re: OpenEuphoria's Strategy
- Posted by SDPringle Feb 06, 2015
- 2454 views
For myself, I was against dropping DOS support, and dropping support for other compilers. The argument was is that we were a small dev team but somehow there is always energy to change things like what happens when you pass an atom to length, to add function "in lining" and add delayed referencing. I don't like the way ifdef symbols work. I think Euphoria ought to have only one symbol table.
We have probably over-exploded the feature set of Euphoria. It is beyond our volunteer time (aka time not earning money, or being with family) but a labor of love as it were, to really squash all of the bugs.
Suppose we have one thousand users and one hundred became pay voters. Features could be voted on by these one hundred to implement or not. To become a voter, you would need to pay some monthly dues of say ten dollars. Maybe this incentive system wont work for Euphoria's user base but I suppose it might work with some other project's user base.
Shawn
38. Re: OpenEuphoria's Strategy
- Posted by Shian_Lee Feb 06, 2015
- 2403 views
...Take Euphoria 3.1.1, add 64-bit support, std libraries, compatibility with OSs, few hot built-ins as error handling and Unicode... And the sky is the limit.
Euphoria should fallback to version 3.1.1 or some alpha version of 4.0.x, and keep the core as small as it possibly could be. (Sorry for joining the party late).
That's just my personal opinion, with a lot of respect to the dev team and to OpenEuphoria.
Now, shoot me.
39. Re: OpenEuphoria's Strategy
- Posted by mattlewis (admin) Feb 06, 2015
- 2387 views
...Take Euphoria 3.1.1,
Ugh...I cannot go back to that. It's...painful. Some of the new features (esp. namespaces and forward references) take away some major pain points in writing non-trivial euphoria code.
I really want to get back to the memstruct stuff. That's the only way to get a 64-bit Win32Lib, for one thing.
Matt
40. Re: OpenEuphoria's Strategy
- Posted by SDPringle Feb 06, 2015
- 2393 views
...Take Euphoria 3.1.1, add 64-bit support, std libraries, compatibility with OSs, few hot built-ins as error handling and Unicode... And the sky is the limit.
Euphoria should fallback to version 3.1.1 or some alpha version of 4.0.x, and keep the core as small as it possibly could be. (Sorry for joining the party late).
That's just my personal opinion, with a lot of respect to the dev team and to OpenEuphoria.
Now, shoot me.
Speaking about the implementation of Euphoria's toolset itself, there were a lot of routines that were made builtins that were implemented in EUPHORIA previously. More code means a greater surface for bugs to appear in and it is not about being "afraid of C". Builtins must be implemented for the backend, for the parser, specially implemented for the translator, and two interpreter backends. That's a greater amount of code for bugs to appear and hide in. You potentially could have more run-time type checking in Euphoria's implementation but they are shockingly turned off by default!
Implementing in C, allows us to take advantage of C structures, which is much more portable than writing in Euphoria when you are interfacing with C. Like for std/pcre.e. Now, if you code in Euphoria, you have to adjust your offsets, especially for 32 bit longs or 64 bit longs and 32 vs. 64 bit pointer types. There is absolutely no-parse time checking of structures. Use, tm_hour (from tm_struct in C) to index a Euphoria date struct? The Euphoria interpreter will say 'sure'. In C, this is prevented before you even run the program.
Shawn
41. Re: OpenEuphoria's Strategy
- Posted by ghaberek (admin) Feb 06, 2015
- 2384 views
Ugh...I cannot go back to that. It's...painful. Some of the new features (esp. namespaces and forward references) take away some major pain points in writing non-trivial euphoria code.
Not to mention assign on declaration and declare variables anywhere - those have been a BIG help!
I really want to get back to the memstruct stuff. That's the only way to get a 64-bit Win32Lib, for one thing.
Yes! I have been playing with the memstruct interpreter on 64-bit Linux lately, and I really love having memstructs, but it segfaults when ever I do anything wrong. 
-Greg
42. Re: OpenEuphoria's Strategy
- Posted by mattlewis (admin) Feb 06, 2015
- 2377 views
Ugh...I cannot go back to that. It's...painful. Some of the new features (esp. namespaces and forward references) take away some major pain points in writing non-trivial euphoria code.
Not to mention assign on declaration and declare variables anywhere - those have been a BIG help!
Oh, yeah. I knew I'd forget stuff.
I really want to get back to the memstruct stuff. That's the only way to get a 64-bit Win32Lib, for one thing.
Yes! I have been playing with the memstruct interpreter on 64-bit Linux lately, and I really love having memstructs, but it segfaults when ever I do anything wrong.
Like, bad struct passing to C stuff, or crashes in the interpreter itself? I'm sure there are plenty of bugs in there. Porting Win32Lib has been a big help in generating different ways of using them.
Matt
Forked into: memstruct segfaults
43. Re: OpenEuphoria's Strategy
- Posted by Shian_Lee Feb 06, 2015
- 2364 views
Overall, not convinced at all.
I get the feeling that these great new features damaged the Euphoria community and the stable development badly.
Good tactic without a good strategy is a death wish. Too bad DOS minimal support was dropped - many users felt uncomfortable with this. That's also consideration.
44. Re: OpenEuphoria's Strategy
- Posted by mattlewis (admin) Feb 06, 2015
- 2400 views
Overall, not convinced at all.
I get the feeling that these great new features damaged the Euphoria community and the stable development badly.
I've never gotten that feeling, but if it did, I regret nothing!
Good tactic without a good strategy is a death wish. Too bad DOS minimal support was dropped - many users felt uncomfortable with this. That's also consideration.
I regret nothing about not supporting DOS at all. I never use it, and its primitive nature meant that we'd either be leaving stuff out in the DOS port or that we'd be extremely hampered by following a least common denominator strategy.
The only thing about DOS that was cool was easy pixel graphics. Rob made a dos_rescue library that several people, including myself, worked on to extend and improve that allows you do do that stuff on other platforms:
https://bitbucket.org/mattlewis/dos_rescue
Matt
45. Re: OpenEuphoria's Strategy
- Posted by Shian_Lee Feb 06, 2015
- 2340 views
I know too many people that never did/will use Linux, but much less which never used DOS. DOS is tiny and powerful to do very reliable job, and it is still popular because of its size and simplicity. Dropping DOS was a mistake in my opinion.
Don't buy a big house if you hate cleaning. The team built a very big house - now who's gonna clean it? Who's gonna maintain it? Was it built for nothing? Anybody has the motivation/time/energy to clean the new big house?
What about a smaller house - but less expensive and easy to clean? Did anybody spent a moment to think about 'the day after'?
46. Re: OpenEuphoria's Strategy
- Posted by mattlewis (admin) Feb 06, 2015
- 2376 views
I know too many people that never did/will use Linux, but much less which never used DOS. DOS is tiny and powerful to do very reliable job, and it is still popular because of its size and simplicity. Dropping DOS was a mistake in my opinion.
At the time, I recall asking the community for people who had the same feeling about DOS as you and would be willing to put in work to keep it going. No one raised their hand, IIRC. This sort of thing totally fits Irv's comment about ancient computers.
Don't buy a big house if you hate cleaning. The team built a very big house - now who's gonna clean it? Who's gonna maintain it? Was it built for nothing? Anybody has the motivation/time/energy to clean the new big house?
What about a smaller house - but less expensive and easy to clean? Did anybody spent a moment to think about 'the day after'?
Now you're getting it. This is exactly why we dropped DOS!
So we have more time to do more useful and interesting things (to us, obviously) with euphoria.
Matt
47. Re: OpenEuphoria's Strategy
- Posted by ghaberek (admin) Feb 06, 2015
- 2351 views
Don't buy a big house if you hate cleaning. The team built a very big house - now who's gonna clean it? Who's gonna maintain it? Was it built for nothing? Anybody has the motivation/time/energy to clean the new big house?
What about a smaller house - but less expensive and easy to clean? Did anybody spent a moment to think about 'the day after'?
Now you're getting it. This is exactly why we dropped DOS!
So we have more time to do more useful and interesting things (to us, obviously) with euphoria.
So basically we boarded up a wing of the house with a sign saying, "enter at your own risk."
-Greg
48. Re: OpenEuphoria's Strategy
- Posted by Shian_Lee Feb 06, 2015
- 2332 views
Since you don't get money for this work, then you are right.
As Irv said, I'll go dig my 386. No complains.
Good luck anyways.
49. Re: OpenEuphoria's Strategy
- Posted by katsmeow Feb 06, 2015
- 2336 views
I know too many people that never did/will use Linux, but much less which never used DOS. DOS is tiny and powerful to do very reliable job, and it is still popular because of its size and simplicity. Dropping DOS was a mistake in my opinion.
At the time, I recall asking the community for people who had the same feeling about DOS as you and would be willing to put in work to keep it going. No one raised their hand, IIRC. This sort of thing totally fits Irv's comment about ancient computers.
I raised a paw, but it got hammered back down with the requirement that all OE development required C coding. Plus there's a lot of old resentment in this place. I use a dos console several times a day, and i use EU to call console utilities and dos functions.
Kat
50. +Re: OpenEuphoria's Strategy
- Posted by mattlewis (admin) Feb 06, 2015
- 2314 views
At the time, I recall asking the community for people who had the same feeling about DOS as you and would be willing to put in work to keep it going. No one raised their hand, IIRC. This sort of thing totally fits Irv's comment about ancient computers.
I raised a paw, but it got hammered back down with the requirement that all OE development required C coding.
Yes, that's why I put in the "willing to put in work" qualifier, though I suppose I should have added "and able."
Matt
51. Re: OpenEuphoria's Strategy
- Posted by SDPringle Feb 06, 2015
- 2310 views
It overstates the issue to say all Euphoria work requires C coding. What about Euphoria libraries? What about documentation?
Shawn
52. Re: OpenEuphoria's Strategy
- Posted by katsmeow Feb 06, 2015
- 2289 views
It overstates the issue to say all Euphoria work requires C coding. What about Euphoria libraries? What about documentation?
Shawn
My taskmsg.e and my irc.e were refused, so were my efforts to volunteer on the website and the html docs for OE. It made me feel real useless.
Kat
53. Re: OpenEuphoria's Strategy
- Posted by mattlewis (admin) Feb 06, 2015
- 2307 views
My taskmsg.e and my irc.e were refused, so were my efforts to volunteer on the website and the html docs for OE. It made me feel real useless.
We've heard this version of the story a zillion times. Please stop telling it.
Matt
54. Re: OpenEuphoria's Strategy
- Posted by katsmeow Feb 06, 2015
- 2237 views
We've heard this version of the story a zillion times. Please stop telling it.
Matt
SDPringle asked me, again, so i answered, again. I am still waiting on someone else to donate an irc.e and taskmsgs.e so there can be an official version. I am also still waiting on a "contact the admin" button on this website, because ChrisB's google email didn't work when i tried it a few days ago.
Kat
55. Re: OpenEuphoria's Strategy
- Posted by SDPringle Feb 07, 2015
- 2230 views
We've heard this version of the story a zillion times. Please stop telling it.
Matt
SDPringle asked me, again, so i answered, again. I am still waiting on someone else to donate an irc.e and taskmsgs.e so there can be an official version. I am also still waiting on a "contact the admin" button on this website, because ChrisB's google email didn't work when i tried it a few days ago.
Kat
There is no reason I couldn't add irc.e and taskmsgs.e to my alternative literals branch. I have given up the idea that this will ever go into the default branch. Can you point me to some documentation for them?
Shawn Pringle
56. Re: OpenEuphoria's Strategy
- Posted by katsmeow Feb 07, 2015
- 2255 views
There is no reason I couldn't add irc.e and taskmsgs.e to my alternative literals branch. I have given up the idea that this will ever go into the default branch. Can you point me to some documentation for them?
Shawn Pringle
In May 2014 i gave up irc3.e to Ryan. I just gave up irc4.e to ne1uno on irc. Ry and ne1uno are OE devs. Note again, what i said to ne1uno in the last hour on irc tonight:
[23:06] <katsmeow-afk> that is exactly what you just saw connect and quit as any948871854 [23:06] <ne1uno> ty [23:07] <katsmeow-afk> BECAUSE it CAN connect and quit and log, it's MORE than what any dev wants to be in irc.e [23:08] <katsmeow-afk> so someone is SURE to hack it apart, screw it up, and then bitch about it [23:08] <katsmeow-afk> and while they hack at it, my version which will work when i hack it, will be unofficial, and their hacked version MIGHT become official [23:08] <katsmeow-afk> but they won't update their hacked version with my version [23:09] <katsmeow-afk> ergo, i will be useless again
[23:17] <katsmeow-afk> i don't remember which version of taskmsgs.e works, and which was my dev version [23:18] <katsmeow-afk> yep, i had taskmsgs.e on my website for anyone to get also [23:19] <katsmeow-afk> i'll put that version back up <snip> [23:23] <katsmeow-afk> DesignerThinking.com/taskmsgs.e , which is up now, AGAIN, from 15 months ago, is the last version i had up, and i don't remember if it is the last of my dev versionsI wish i could remain part of my "babies", if any more work is "required" on them (such as the multiserver version of irc.e, which works except it is midway thru a irc.e-irc_client.exw split and not suitable for release). I am pretty sure i'll be kicked out of them.
Kat
57. Re: OpenEuphoria's Strategy
- Posted by jimcbrown (admin) Feb 07, 2015
- 2195 views
It overstates the issue to say all Euphoria work requires C coding. What about Euphoria libraries? What about documentation?
Shawn
Perhaps, but this is certainly true when it comes to maintainenance (or revivial) of the DOS port.
58. Re: OpenEuphoria's Strategy
- Posted by SDPringle Feb 07, 2015
- 2175 views
I wish i could remain part of my "babies", if any more work is "required" on them (such as the multiserver version of irc.e, which works except it is midway thru a irc.e-irc_client.exw split and not suitable for release). I am pretty sure i'll be kicked out of them.
Kat
I have lots of finished and unfinished projects sitting on my hard disc that might never see the light of day. The trick is to try to create start things that will be small enough to finish.
59. Re: OpenEuphoria's Strategy
- Posted by Shian_Lee Feb 07, 2015
- 2188 views
The trick is to try to start things that will be small enough to finish.
It's not a trick, it has many other names, such as:
Wisdom; Maturity; Being Realistic; Modesty; Being Practical; Being Balanced; ...
The above qualities are not so common on Earth, that's why it consider as trick.
But thank you for reminding it (It's already mentioned 2,300 years ago in China area by Lao Tse).
60. Re: OpenEuphoria's Strategy
- Posted by katsmeow Feb 07, 2015
- 2216 views
I wish i could remain part of my "babies", if any more work is "required" on them (such as the multiserver version of irc.e, which works except it is midway thru a irc.e-irc_client.exw split and not suitable for release). I am pretty sure i'll be kicked out of them.
Kat
I have lots of finished and unfinished projects sitting on my hard disc that might never see the light of day. The trick is to try to create start things that will be small enough to finish.
There is a difference between me not finishing them for my own reasons, and someone else forcing me out of the finishing.
Kat
61. Re: OpenEuphoria's Strategy
- Posted by jimcbrown (admin) Feb 07, 2015
- 2196 views
I wish i could remain part of my "babies", if any more work is "required" on them (such as the multiserver version of irc.e, which works except it is midway thru a irc.e-irc_client.exw split and not suitable for release). I am pretty sure i'll be kicked out of them.
Kat
I have lots of finished and unfinished projects sitting on my hard disc that might never see the light of day. The trick is to try to create start things that will be small enough to finish.
Agreed. I think another part of it is motivation. I once chatted with a fellow - Paul Brook of Cygnus Solutions - who said something along the lines of, "If it's not going to be accepted and committed, I see no point in writing the first line of code for it."
Obviously, I disagree - I think people should code for the joy of coding, not for the purpose of getting stuff submitted. (At least in Mr. Brook's case, the rationale made a little more sense - he got paid to code on FOSS. But AFAIK that's not the case for anyone here.)
It's easy to get demotivated to finish a project you've started. (E.g. "it'll take several months before anyone has time to review a patch of that size" -> patch never gets written.) It's even worse if you want to be the one person who exclusively has access to and approves changes for the part of the code that you worked on and submitted to another project. That almost never happens .. since that's simply not how FOSS works.
Edit: I imagine that some people, trying and failing to get their code submitted along their standards (instead of the standards of the project that they are submitting their code to), may feel as they have been forced from finishing their coding. However, I think this is just another form of getting demotivated to finished - it's not like the project team broke into a coder's house and destroyed the computers there, or tied the coder to a chair until the coder promised not to finish the code. The coder can certainly finish what the coder started. In more extreme cases, coders can prove that they are right and the project team is wrong simply by forking the project and doing things their way.
62. Re: OpenEuphoria's Strategy
- Posted by ne1uno Feb 07, 2015
- 2170 views
There is no reason I couldn't add irc.e and taskmsgs.e to my alternative literals branch. I have given up the idea that this will ever go into the default branch. Can you point me to some documentation for them?
Shawn Pringle
In May 2014 i gave up irc3.e to Ryan. I just gave up irc4.e to ne1uno on irc. Ry and ne1uno are OE devs. Note again, what i said to ne1uno in the last hour on irc tonight:
[23:06] <katsmeow-afk> that is exactly what you just saw connect and quit as any948871854 [23:06] <ne1uno> ty [23:07] <katsmeow-afk> BECAUSE it CAN connect and quit and log, it's MORE than what any dev wants to be in irc.e [23:08] <katsmeow-afk> so someone is SURE to hack it apart, screw it up, and then bitch about it [23:08] <katsmeow-afk> and while they hack at it, my version which will work when i hack it, will be unofficial, and their hacked version MIGHT become official [23:08] <katsmeow-afk> but they won't update their hacked version with my version [23:09] <katsmeow-afk> ergo, i will be useless again
[23:17] <katsmeow-afk> i don't remember which version of taskmsgs.e works, and which was my dev version [23:18] <katsmeow-afk> yep, i had taskmsgs.e on my website for anyone to get also [23:19] <katsmeow-afk> i'll put that version back up <snip> [23:23] <katsmeow-afk> DesignerThinking.com/taskmsgs.e , which is up now, AGAIN, from 15 months ago, is the last version i had up, and i don't remember if it is the last of my dev versionsI wish i could remain part of my "babies", if any more work is "required" on them (such as the multiserver version of irc.e, which works except it is midway thru a irc.e-irc_client.exw split and not suitable for release). I am pretty sure i'll be kicked out of them.
Kat
there is an over 4 year old open ticket to add irc,e to the networking suite. I don't know why this wasn't done earlier. (or care)
task messages between tasks will be a nice functionality to add to task.e and I can't imagine anyone that uses tasks would find the code anything but useful. it was brought up on the forum before and somehow the process got tanked. no matter. I saved an earlier version of the code in euqt, but didn't want to move it into task.e until Kat actually donated it to openeuphoria directly. we don't have a formal process for this but posting the code to the ticket system once done should be enough.
euphoria style guidelines, adding doc comments, a few redundant functions from the stdlib removed, a few include statement changes, finishing the split out of the demo client from irc.e and some test routines are all that the code needs. it's only a few dozen lines.
I will post on the ticket system and forum once that is done. won't happen this weekend.
we should remember, for many of the forum posters, English is not their first language and never attribute to malice what can better be described as stupidity or something like that in relation to any comments about the code or the coder when it comes to adding or taking away something from euphoria syntax.
it's all just syntax, not that big a deal. show me the docs and I can figure out a way to do it.
63. Re: OpenEuphoria's Strategy
- Posted by katsmeow Feb 07, 2015
- 2148 views
euphoria style guidelines, adding doc comments, a few redundant functions from the stdlib removed, a few include statement changes, finishing the split out of the demo client from irc.e and some test routines are all that the code needs. it's only a few dozen lines.
Ne1uno, respectfully and pleadingly, if you intend to alter the irc.e code i submitted, i want to see and run tests on the code after you alter it. I duplicated a little code from the std libs because of path issues mostly. Some devs hacked code i submitted before, and could not get it to work, and at least one did/n't hack an unknown version i do not recall giving him and he couldn't get it to work. I also want to see if you changed it so much that my irc6.e and irc_client6.exw is still valid or i should quit working on them. I have a cute trick i want to try, but not if it isn't going to be considered, or if you will be editing it out anyhow.
Regarding the taskmsgs.e , using that with news.e and http.e makes them multitask much better than without. I was hoping to get http.e to taskmsg the entire webpage it was retrieving, but there was something fishy about a function call needing to complete anyways, or something. However, that's when run interpreted. If they don't run tasks when compiled, ummm, then stop working on the compiler, please. But otherwise, due to interactions with the devs, i gave up so hard and definately, i don't remember (and didn't bother to look) which was the last best version completed. I remember i deleted some code, i think i deleted the entire directory, and all that wasn't deleted was in the news.e dir, and a single copy of what was on my website.
Kat
64. Re: OpenEuphoria's Strategy
- Posted by jimcbrown (admin) Feb 07, 2015
- 2141 views
If they don't run tasks when compiled, ummm, then stop working on the compiler, please.
Tasks work fine when compiled.
65. Re: OpenEuphoria's Strategy
- Posted by ne1uno Feb 07, 2015
- 2153 views
If they don't run tasks when compiled, ummm, then stop working on the compiler, please.
Tasks work fine when compiled.
there is one special case when yeild() is called in a dll it is ifdef'ed out. probably should include a console message, warning trip or something to that effect when built somehow. seems unwise to just have it silently drop out of the code, but I don't recall all the details of why this was done.
