1. SWITCH question
- Posted by jessedavis Dec 15, 2017
- 3082 views
I notice that the home page of this forum shows example code of a typical switch routine. Does this mean that the problems with switch in the current version of euphoria have been fixed?
2. Re: SWITCH question
- Posted by irv Dec 24, 2017
- 2933 views
It seems not to have been fixed, at least in 4.1.0 development version. Strangely, the error seems to depend upon the position of the arguments:
include std/dll.e -- this fails switch 1 do case C_HANDLE then case C_POINTER, C_HANDLE then end switch
A machine-level exception occurred during execution of this statement (signal 11)
include std/dll.e -- this works: switch 1 do case C_HANDLE then case C_HANDLE, C_POINTER then end switch
duplicate values in a switch: C_HANDLE and C_HANDLE
include std/dll.e -- this also works: switch 1 do case C_POINTER, C_HANDLE then case C_HANDLE then end switch
duplicate values in a switch: C_HANDLE and C_HANDLE
include std/dll.e constant HANDLE = C_HANDLE, POINTER = C_POINTER -- this helps! switch 1 do case HANDLE then case POINTER, HANDLE then end switch
<0063>:: duplicate case value used. case POINTER, HANDLE then
All this is very curious. I wonder if the sig 11 might be in the error reporting routine (perhaps passing a zero index?)
3. Re: SWITCH question
- Posted by Ekhnat0n Dec 25, 2017
- 2806 views
What abut this solution:
C_USE={C_HANDLE,C-POINTER}
SWITCH C_USE
...CASE !C_USE[1] then
......INV_HNDL_MSG) INV_MSG= {"invalid handle in {module, line}} & fallthrough
......IF !(C_USE[2]) INV_MSG= {"invalid pointer in handle,{module,handle,line} ENDIF & fallthrough
....../* Action can follow safely */
...CASE any_other_case INV_MSG= {"No handler->pointer: ",{module,line}, "solution available yet" )
... === etc for multiple sig's
...DEFAULT (default-handling for non selected cases) ...Return (if any, the error=messages, if not... signal the unknown error)
ENDSWITCH
I know the coding in itself is incorrect, but the logic is ok
I´ve been too long outof commission and would have to look up the correct code for each part of the flow, you all OTOH will exactly know what the correct keywords and their parameters are.
SO, take this flow, correct it's syntax and the error or unpredictability will no longer be there
4. Re: SWITCH question
- Posted by irv Dec 25, 2017
- 2771 views
Are there currently any problems with switch() other than the outlier mentioned above?
I've been using it for a long time with no problem, but I have never had a need to use it directly with C_HANDLE, C_POINTER, etc., since in order to save a lot of typing, I generally assign a shorter alias for each: e.g. constant P = C_POINTER, H = C_HANDLE, etc.
As shown in the tests above, this works properly.
5. Re: SWITCH question
- Posted by jessedavis Dec 28, 2017
- 2688 views
Are there currently any problems with switch() other than the outlier mentioned above?
I've been using it for a long time with no problem, but I have never had a need to use it directly with C_HANDLE, C_POINTER, etc., since in order to save a lot of typing, I generally assign a shorter alias for each: e.g. constant P = C_POINTER, H = C_HANDLE, etc.
As shown in the tests above, this works properly.
I stood before this forum and vowed never to use switch again. This said, it is nice to have a working switch as it is much easier than writing the equivalent with if, else, elsif, etc. and the code is easier to read and understand. I spent considerable time working on this problem (see my posts of a year ago (or so)). The conclusion I came to was pointers were not being correctly handled. I proved that the values of CONSTANTS were being changed by the switch routine. This leads to erroneous outcomes and machine level faults. I am not a capable enough programmer to fix this. It would be nice if someone would take the time to examine the problem and fix it.
regards,
jd
6. Re: SWITCH question
- Posted by Ekhnat0n Dec 28, 2017
- 2702 views
- Last edited Dec 29, 2017
Hello jd,
Primarily a healthier, happier and more prosperous New Year than any you have had until this one.
Secondarily your request:...
Please gimme me a link to where I can find the switch... case... default... end switch thing in the docs and includes
and I will look into the possible logical error that might lurk in there.
Switch has to put a number of possible return-addresses on the stack for the cases and the default.
If those addresses, for reasons yet unknown, aren't removed properly, you will surely get erroneous return after that, which might well be in the constants-table Eu keeps.
As I known enough of C(& C with OOP) and 86.?? Assembly language to get a grasp of what is going on "under the hood" I might be able to correct that.
Mind you, I am not telling I will be able to do so, just MIGHT be able, but if I can't do it myself
because I have been "out of the match" for over 5 years in OE or it's parent,
I will be able to put my finger on the exact spot where things go wrong
and the "ignition" of the engine looses its correct timing.
I would have to go all over the whole documentation and because of my recent involvement in an other project
I won't take out the time to do so, BUT if you give me the include-lib where switch-etc is defined, I will surely check that within at most next fortnight, max 3 weeks.
Antoine/Netherlands. Credentials:
7. Re: SWITCH question
- Posted by jessedavis Dec 30, 2017
- 2642 views
Please gimme me a link to where I can find the switch... case... default... end switch thing in the docs and includes
and I will look into the possible logical error that might lurk in there.
Go here: http://scm.openeuphoria.org/hg/euphoria/archive/tip.zip
look in execute.e (among other spots) line #1668
procedure opSWITCH_RT() -- Analyze the values, and update to the appropriate type of switch -- Then call it -- pc+1: switch value -- pc+2: case values -- pc+3: jump_table -- pc+4: else jump
Good Luck!
regards,
jd
8. Re: SWITCH question
- Posted by Ekhnat0n Dec 31, 2017
- 2551 views
Hi jd,
After a good night's rest and some paracetamolum-ish thingy (ending an excruciating migraine)
I did realize I had been too sleepy the moment I answered your question and I'd better have waited
until the clouds were gone and I could clearly see the way again.
There is absolutely NO flaw in switch - - - case(s) - - - default - - - endswitch.
The flaw is a logical one in the way you treat switch, because you don't use the METHOD of switch correctly.
Explaining its method is simple:
Switch emulates a specific type of conditional for next loop
for a={1,2,3,4,5,6,7,8,9,x}, /* do something */ step +=1 next a end for a
It does in case of a=1 the action pertaining to a[1] etc but it is recursive so if a[1] would be {x1,y1,z1} it will perform x,y,z in that order.
before stepping up to [a2], and finishing AFTER {a[x][y]} finished, leaving
a condition If none of the specified conditions is met, it CAN perform a DEFAULT action
So in fact with creating sequences and manipulating them the way you like
he created a sequential for, if, while etc possibility.
The potential of it is unbelievable. It offers you the option of writing very complex
logical structures in an absolutely logical way, hell NO it creates the option of
writing impossible functions in a dedicated system, by simply telling itself
ON YOUR COMMAND to change eg it's number-base and implicitly its NEW method.
EG: 2/3 in binary you cannot solve, and it will introduce growing inaccuracies,
Well, tell EU to switch to Ternary and it will be able to solve at least half o
the 2 vs three questions, without ANY LOSS of precision.
The only inaccuracy will be in translating the 3-base number back into a binary value.
Check carefully what you ASK switch to do and the anomalies will disappear, NOT
giving it nonsensical commands within its method, solves all of them.
SWITCH is AUDAIS (Almost Unlimited Descriptive Artificial Intelligent System) IF
you have the capacity of perfect structuring, it will be the only existing tool (programming language-wise)
in the whole world. That is the power ONLY old Euph already had, and believe me:
I doubt whether Rob and Junko themselves saw this perspective.
And THAT POWER is a feature ONLY OE and EU (+phix) have that NO OTHER PL has.
9. Re: SWITCH question
- Posted by irv Dec 31, 2017
- 2521 views
Perhaps there's no flaw in the switch statement, but there certainly is in its error reporting.
Being able to correctly report an error if certain conditions exist in one particular order, but crashing with a segfault if the same conditions exist in a different order is inconsistent, and not very helpful to the programmer.
IOW, not what is expected from Euphoria.
10. Re: SWITCH question
- Posted by Ekhnat0n Jan 01, 2018
- 2535 views
You could tackle this problem from several sides.
1) exactly stating its erratic behaviour, and go on using it the way it yields non-erratic results
in the meantime analizing under which different condition(s) it behaves predictable, using those cases as "hidden features" until the erratic behaviour as a whole can be predicted .perfectly
2) Analise in depth WHAT it does that seems to be erratic and start using it once that problem is finally solved
OR the erratic behaviour can be put down in ONE simple rule.
Those are the 2 most obvious roads to explore, number 1 is my personal choice, because it will solve quite a number of program-flows in a very neat and ordered way.
As I simply have neither time nor resources to do it all on my own, i will need help in both areas, providing me with (beta) test-results and a minor practical resource support.
What kind of practical support I don't know yet, because, though a financial support might enable me to upgrade my productivity and give me more "spare" time to tackle the nastiest bug(s) in it myself at a far higher speed. It would allow me to acquire a good S2T-engine and a number of vocabularies and voices to go with a T2S module backend
This could be in the form of a small financial contribution to make it possible to buy a good S2S-T2S system.
The practical way has a second (and 3rd) option.
1)IF by any chance you already have this software, you could make it available to me on my laptop asap by sending me a .deb package of it.
If you have to break EULA's for it, it would be at your risk, but ofc I would never ever tell anybody what you did.
2) Any possible combination of both options mentioned.
THIS GOES for anybody else wanting to participate in enhancing OE's features in all possible ways.
11. Re: SWITCH question
- Posted by kinz Jan 01, 2018
- 2503 views
The flaw is a logical one in the way you treat switch,
because you don't use the METHOD of switch correctly.
Implemented "the METHOD of switch" is too complicated, IMHO.
But there was some big discussion in 2009 about possible implementation ways:
http://openeuphoria.org/forum/105470.wc#105470
Regards
kinz
12. Re: SWITCH question
- Posted by Ekhnat0n Jan 01, 2018
- 2551 views
The PRIMARY method of switch is:
Case 1: JUST do Case_1 things (If that is all you want it to do, then signal "SUCCESS" and LEAVE the switch.
This goes for any SINGLE-action situation.
In this way it is no more tan a LIST of IF...Endif's
BUT if you let SWITCH do what it is capable of, it will go on doing case_2 things that need to be done (immediately) after case_1 was either T or F
YOU decide whether to go on and perform its next "task" (New piece of code OR error-handling, before entering case_3.
IF a condition is not met successfully, THAT particular case drops out of SWITCH with a FALSE result and the module/line & error causing it, and WHERE YOU caused it (WHICH Handle and pointer and the kind of violation (EG x/0 or DIV(0,x) and DIV(x,0). A second example, it would send you a TYPE-mismatch message.
Does that clarify its METHOD(s) sufficiently?
Example: I want you go buy something for me, but forget to give you (necessary) money in advance:
The correct coding would be:
Does X have sufficient money to pay for what I asked him to buy for me?
If NOT provide him with it before sending him off.
On X's return, ask him for the goods AND ONLY if he hasn't bought EXACTLY what I told him
AND that would make it impossible for me to do what I need to do in the end,
throw an error-message: Operation impossible by X not doing what X ought to do (neither having done so) AND have him fetch the correct {tool,material,support}
JOB FINISHED SUCCESSFULLY
Does this example blow away the clouds or nebulae on Switches FULL METHOD?
13. Re: SWITCH question
- Posted by jimcbrown (admin) Jan 01, 2018
- 2548 views
Go here: http://scm.openeuphoria.org/hg/euphoria/archive/tip.zip
look in execute.e (among other spots) line #1668
There is absolutely NO flaw in switch
The reason you can't find any issue there is because you're looking in the wrong place. execute.e is used only by eu.ex but that is not the module that is crashing. (It's not immediately obvious to me which module is responsible for the crash, but be_execute.c is the analog for the C-based backend - search for L_SWITCH (but note that we have a couple of them, e.g. L_SWITCH_I and L_SWITCH_RT).)
Perhaps there's no flaw in the switch statement, but there certainly is in its error reporting.
Being able to correctly report an error if certain conditions exist in one particular order, but crashing with a segfault if the same conditions exist in a different order is inconsistent, and not very helpful to the programmer.
IOW, not what is expected from Euphoria.
Agreed.
You could tackle this problem from several sides.
1) exactly stating its erratic behaviour, and go on using it the way it yields non-erratic results in the meantime analizing under which different condition(s) it behaves predictable, number 1 is my personal choice
But irv already did that: http://openeuphoria.org/forum/m/131707.wc
It would allow me to acquire a good S2T-engine
Why do you need a speech-to-text/text-to-speech engine in the first place? Doesn't sound like it has anything to do with this thread.
If you have to break EULA's for it, it would be at your risk, but ofc I would never ever tell anybody what you did.
On this website that sort of thing is strictly forbidden. The good news is that it's also not necessary - there's a good open source text-to-speech system for download at http://espeak.sourceforge.net/download.html and http://cmusphinx.sourceforge.net/ for speech-to-text.
14. Re: SWITCH question
- Posted by petelomax Jan 01, 2018
- 2505 views
If I may step in and summarize what has already been said, the thing that is broken is:
Duplicate case entries trigger a compilation error
But http://openeuphoria.org/docs/lang_branch.html#_147_switchstatement does not actually state that, and apparently the compiler does not always implement it correctly (but sometimes it does!).
We are quite used to this
if x=17 then ?"x is 17" elsif x=17 then ?"x is 17 as well" end if
simply (and not really very helpfully) effectively just ignoring the second branch, whereas
switch x do case 17: ?"x is 17" case 17: ?"x is 17 as well" end switch
sometimes crashes, presumably trying to put 17 in the jump table twice. (but use the real examples from #2 above instead)
NB: we do not give a flying monkeys what that should do were it to somehow compile correctly; it should give a compilation error and not run.
One thing that has just struck me is that if the compiler assumes the jump table entry is 0 or some predetermined base offset when calculating jump_table[17]... not that such explains the sporadic behaviour.
Actually, I suspect irv was right and that it is crashing when trying to report the error.
HTH, Pete
15. Re: SWITCH question
- Posted by Ekhnat0n Jan 01, 2018
- 2505 views
Hello jim,
First of all Happy New Year to you and those who are close to you.
Why do I need S2T & T2S?
1) I Can communicate a hell of a lot faster that way. Anything taking me an hour to type-out only costs me 10 minutes at most to SAY. Being able to go faster by a factor 6 means
1) I can produce 6² times faster than I can do possibly now, and with far less effort and errors.
2) Which intrinsically means I can explore 36 more ways Each with their own METHOD.
As the consequence of finding ONE new method is
that I will be able to advance to investigate 6! possibilities (720) whereas before that could only do 120.
Finding the next barrier to be able to communicate perfectly at thought-speed might get nearer, and will only be limited by the relative enhancement of this speed, you agree?
Well this is the way those authors who write books on a monthly or weekly base have to do (unless they let a 'puter generate them.
As right now I am thinking approximately 1000 times faster than I speak, tossing over thought-experiments and throwing out (on average 9 in 10) 100 will remain in the same time I threw out JUST 1 thought right now, it means I can unleash a much larger part of my capacity(ies) and find viable ways to tackle a new problem from far more sides in a significant shorter period.
I am however sure, that SWITCH can perform in more ways, with each parameter (choice) you add to it in a PREDICTABLE (number of) way(s), hence finding the correct formula will be a bit tricky, because the linear ORDER of things to test will be very important as I did prove in my example in my last post in this tread. 2 numbers have 2 different ways to interact. 1+1=2 1-1=0 that is ONLY true for 0,1 and 2. go do your math on 3 numbers (1, 2 and 3) There are ONLY 2 ways to have them result in 6 that are the same. 1+2+3==1*2*3.
But as 1 didn't contribute in the multiplication it DID in the addition. We are simply applying the laws of arithmetic here in a 2 dimensional plane.
What if we would start applying it in 3D? That is what I really am working at ATM.
BTW my apologies for transgressing the C0C if this forum, nowhere in the concise header is to be found, that I would not turn down any (temporary) help whatsoever and what consequences are involved. Nor is soliciting for such aid to be found as against the Code of Conduct ;)
Forked into: OT: S2T & T2S (non-Eu)
16. Re: SWITCH question
- Posted by jimcbrown (admin) Jan 01, 2018
- 2486 views
If I may step in and summarize what has already been said, the thing that is broken is:
Duplicate case entries trigger a compilation error
But http://openeuphoria.org/docs/lang_branch.html#_147_switchstatement does not actually state that
HTH, Pete
Ah, yes. I'm more comfortable leaving this to _tom to deal with (when he gets back from the holidays I suppose) but the docs should be fixed.
Actually, I suspect irv was right and that it is crashing when trying to report the error.
Sounds reasonable. Either way, it seems that we have two issues.
17. Re: SWITCH question
- Posted by Ekhnat0n Jan 01, 2018
- 2461 views
I second Pete's analysis. It is in fact a left-over jump-addr. on the stack causing the behaviour as I explained in the wrong thread (S2T T2S)
18. Re: SWITCH question
- Posted by jessedavis Jan 03, 2018
- 2438 views
simply (and not really very helpfully) effectively just ignoring the second branch, whereas
switch x do case 17: ?"x is 17" case 17: ?"x is 17 as well" end switch
The compiler will not allow two cases with the save value. All this is very good; but, my original problem with SWITCH was that the value of case constants was being changed during the execution of the method. This leads to real problems.
Regards,
jd
19. Re: SWITCH question
- Posted by Ekhnat0n Jan 03, 2018
- 2410 views
Hi jd,
Just treat the returned value as a sequence of Boolean answers to the resp. cases.
I couldn't test it yet, because right now I am having Kdb troubles, trying to integrate a BT Kbd with an applelayout to my Ubuntu 16.04. Somehow it's gping wrong, so I end up with my LenovoKbd US with dead keys acting like an apple kbd AND not finding the BT connectfor the apple one which i am almost sure will have the correct layout for all special chars. I already did reboot and do a cold restart to have the OS find the thingy, but as for now, in vain.
20. Re: SWITCH question
- Posted by _tom (admin) Jan 05, 2018
- 2355 views
I made a start on re-writing the description of the switch statement.
http://openeuphoria.org/wiki/view/Updated%20Documentation.wc
problem one
There are three possible error messages reported for having duplicate case values in a switch statement. I also got different results (same example) using OE on a 32-bit and 64-bit computers.
Something to do with parsing and error reporting? Ugly but not serious?
problem two
A real mystery in how a constant formed from std/stack.e crashes the switch statement. JD suggests a pointer problem.
Not a trivial bug.
_tom
21. Re: SWITCH question
- Posted by irv Jan 05, 2018
- 2364 views
More problems with the switch statement:
Example 1
include std/stack.e constant op = stack:new(FIFO) ? op constant stk = op ? stk switch stk do -- err line case op then puts(1, "\n result is first stack \n" ) case else puts(1, "\n result is something else \n") end switch
1
1
/home/irv/stk.ex:9 A machine-level exception occurred during execution of this statement (signal 11)
Example 2
include std/stack.e atom op = stack:new(FIFO) ? op atom stk = op ? stk switch stk do case op then -- err line has moved puts(1, "\n result is first stack \n" ) case else puts(1, "\n result is something else \n") end switch
/home/irv/stk.ex:10
<0091>:: found variable but expected 'else', an atom, string, constant or enum
case op then
Notice, please, that this second version has two problems:
- It did not print the two 1s, unlike the first program
- Secondly, what does that error message even mean????
Given the difference, I suspect the problems exist in at least two separate places. The first example fails in the actual switch function, and the second is in an earlier step (parsing?).
Clearly, there are some major problems with switch!
Just to clarify that it isn't (all) a result of using std/stack, I submit this example:
Example 3
atom stk = 1 ? stk atom op = stk ? op switch stk do case op then -- err here again puts(1, "\n result is first stack \n" ) case else puts(1, "\n result is something else \n") end switch
/home/irv/stk.ex:8
<0091>:: found variable but expected 'else',an atom, string, constant or enum
case op then
Am I misunderstanding something? I could swear that everything in there was atoms!
22. Re: SWITCH question
- Posted by jimcbrown (admin) Jan 05, 2018
- 2524 views
More problems with the switch statement:
Example 2
include std/stack.e atom op = stack:new(FIFO) ? op atom stk = op ? stk switch stk do case op then -- err line has moved puts(1, "\n result is first stack \n" ) case else puts(1, "\n result is something else \n") end switch
/home/irv/stk.ex:10
<0091>:: found variable but expected 'else', an atom, string, constant or enum
case op then
Notice, please, that this second version has two problems:
- It did not print the two 1s, unlike the first program
the second is in an earlier step (parsing?).
That's correct. You are getting a parse-time error, so that's why nothing was printed - no code had been executed yet at this point.
- Secondly, what does that error message even mean????
The value in a case statement must be a constant - variables aren't allowed.
I asked Jeremy about this once and he said by restricting it to constants we could optimize and make switch faster than if-else. He pointed out that this is also how the statement works in C.
Example 3
atom stk = 1 ? stk atom op = stk ? op switch stk do case op then -- err here again puts(1, "\n result is first stack \n" ) case else puts(1, "\n result is something else \n") end switch
/home/irv/stk.ex:8
<0091>:: found variable but expected 'else',an atom, string, constant or enum
case op then
Am I misunderstanding something? I could swear that everything in there was atoms!
op is a variable whose value can change, not a fixed constant whose value is known at parse-time.
23. Re: SWITCH question
- Posted by irv Jan 05, 2018
- 2340 views
It appears that the docs are slightly misleading:
4.4.2 Switch statement The <val> in a case must be either an atom, literal string, constant or enum...
atom expr = 1 atom val = x -- * switch expr do case val then puts(1, "\n result is first stack \n" ) case else puts(1, "\n result is something else \n") end switch
<0091>:: found variable but expected 'else', an atom, string, constant or enum
case val then
So, val must be declared as a constant, or an enum. Otherwise, the val must be literal. e.g:
case 1 then ... case 1.23 then ... case "Five" then ..
IOW, val must never be anything that is 'changeable'.
Secondly, switch() is not exactly comparable to a if..then..else statement, since if..then can deal with variables as the val,(including changing them within the statement).
Perhaps the docs could be improved to make this distinction clearer, as well as emphasizing the fact that you should never use duplicate switch cases. Apparently, I haven't run across that particular problem in real life, because I'm too lazy to type the same case ... twice.
24. Re: SWITCH question
- Posted by irv Jan 05, 2018
- 2309 views
Could it be that we are looking in the wrong place for the cause of the sig 11 crash? Note that assigning one constant to another fails, while assigning the equivalent literal value to that same constant succeeds:
constant expr = cos(0) ? expr constant val = 1 -- works ? val switch expr do case val then puts(1, "\n result is first stack \n" ) case else puts(1, "\n result is something else \n") end switch
1
1
result is first stack
constant expr = cos(0) ? expr constant val = expr -- fails ? val switch expr do case val then puts(1, "\n result is first stack \n" ) case else puts(1, "\n result is something else \n") end switch
1
1
/home/irv/stk.ex:7
A machine-level exception occurred during execution of this statement (signal 11)
constant expr = cos(0) ? expr constant val = cos(0) -- fails (it's the same, but different!) ? val switch expr do case val then puts(1, "\n result is first stack \n" ) case else puts(1, "\n result is something else \n") end switch
Also fails, same error.
25. Re: SWITCH question
- Posted by _tom (admin) Jan 05, 2018
- 2283 views
It appears that the docs are slightly misleading:
...
Perhaps the docs could be improved to make this distinction clearer, as well as emphasizing the fact that you should never use duplicate switch cases. Apparently, I haven't run across that particular problem in real life, because I'm too lazy to type the same case ... twice.
The docs are http://openeuphoria.org/wiki/view/Updated%20Documentation.wc
My suggestion is WRITE COMMENTS DIRECTLY INTO THE WIKI DOCS, ANYTHING UNCLEAR HAS TO BE FIXED.
My other observation with this "std/stack.e" example is that if you compile, then the example it works.
_tom
26. Re: SWITCH question
- Posted by irv Jan 05, 2018
- 2274 views
Yes, I can confirm that all 3 run properly when compiled.
27. Re: SWITCH question
- Posted by petelomax Jan 05, 2018
- 2314 views
Yes, I can confirm that all 3 run properly when compiled.
Hate to say it, but I would wager that is the result of constant propagation, ultimately in effect a red herring of little to no help at all here.
During interpretation, after a=1 b=a, the interpreter still thinks b is variable, obviously it may yet be assigned to something else later on, but when compiling, after some (repeated) whole-program analysis, it ends up knowing that b can only be 1, and then gets to treat it as a constant [and in fact that is exactly what a constant (literal integer) is: a variable with min==max]. It doesn't do that extra analysis when interpreting, for obvious performance reasons.
Pete
28. Re: SWITCH question
- Posted by Ekhnat0n Jan 05, 2018
- 2316 views
Maybe
OE switch-statement might be a victim of lots of newer Intel-chips bug. RE https://be.hardware.info/nieuws/54729/bug-in-intel-processors-lekt-data-uit-kernel-oplossing-verlaagt-prestaties-aanzienlijk
I'm sorry presenting you with a (Flemish)/Dutch page, I didn't even take time to check their English page, so please find the translation, because I could read it perfectly, as Dutch OFC is my mothertongue
29. Re: SWITCH question
- Posted by irv Jan 05, 2018
- 2293 views
Simplest example, uses the switch from above:
constant expr = cos(0) -- cos(0) returns 1, as do map:new, etc... constant val = expr -- so built-in and library functions fail when interpreted constant expr = foo(0) -- my foo(x) returns x+1 constant val = expr -- this works. Why is my function so much better than the built-in ones?
Hopefully, someone can explain that.
30. Re: SWITCH question
- Posted by _tom (admin) Jan 05, 2018
- 2302 views
...
Hopefully, someone can explain that.
I typed up your examples to "cut-and-paste" form so others can test them.
A OE built-in function: FAIL.
constant op = cos(0) ? op -->1 switch 1 do case op then puts(1, "\n result is first stack \n" ) case else puts(1, "\n result is something else \n") end switch --> FAIL
A home-brew function: SUCCESS
function foo( atom x ) return x+1 end function constant op = foo(0) ? op -->1 switch 1 do case op then puts(1, "\n result is first stack \n" ) case else puts(1, "\n result is something else \n") end switch --> success
An attempt to sanitize the return from an include file: FAIL
include std/stack.e function OP( ) object x = stack:new(FIFO) return x /* -- this version works if x=1 then return 1 end if */ end function ? OP() constant op = OP() ? op -->1 switch 1 do case op then puts(1, "\n result is first stack \n" ) case else puts(1, "\n result is something else \n") end switch --> FAIL
Testing idea that it's a scope or namespace problem.
Home-made include file: success.
-- mylib.e export function foo( atom x ) return x+1 end function
include mylib.e constant op = foo(0) ? op -->1 switch 1 do case op then puts(1, "\n result is first stack \n" ) case else puts(1, "\n result is something else \n") end switch --> success
OE functions, built-in and std/lib, are possessed.
_tom
31. Re: SWITCH question
- Posted by irv Jan 05, 2018
- 2247 views
OE functions, built-in and std/lib, are possessed.
_tom
So it appears :(
No wonder some people refuse to use switch.
32. Re: SWITCH question
- Posted by petelomax Jan 05, 2018
- 2315 views
I think we you lot need to step back and focus on the C_HANDLE issue as raised in post #2.
This cos(0)/foo(0)/op=stack:new(FIFO);stk=op etc stuff is, I fear, just muddying the waters. Fix one thing at a time, eh?
With that in mind, I have a question. Given that std/dll.e says
C_UINT = #02000004, C_POINTER = C_UINT, C_HANDLE = C_UINT,
does the situation change if we you have (one or both of)
C_POINTER = #02000004, C_HANDLE = #02000004,
I will admit that I actually completely missed that C_POINTER and C_HANDLE are in fact the same value!
Pete
33. Re: SWITCH question
- Posted by _tom (admin) Jan 06, 2018
- 2248 views
I think we you lot need to step back and focus on the C_HANDLE issue as raised in post #2. ...
Royal we?
On my 32-bit netbook there is no crash. Just different error messages as the arguments are moved about. On my 64-bit netbook I get the crash.
There is an additional rule that says the symbols must be different. Within one case you can have two different symbols with the same value:
-- docs say you can have a duplicate value in a case -- if the symbols are different constant H = 1 constant P = 2 constant HP = 2 switch 1 do case H then case P , HP then end switch -- no error
We thank you Pete
_tom
34. Re: SWITCH question
- Posted by Ekhnat0n Jan 06, 2018
- 2207 views
Well Pete, and all of you, WHO did I second?
WHY did I second him the moment I saw that post?
BECAUSE it would only take HIM 1 more step to get to the METHOD of SWITCH and he would so WITHIN HOURS after having ONE MORE deep thought!
GUESS NOW, who KNEW all along?
AND WHY!
I CAME TO FIND THAT SOLUTION LONG TIME AGO, BUT SIMPLY FORGOT TO APPLY IT IN THIS AREA,
UNTIL I realised being called delusional, and worse when I told you MY KNOWLEDGE,
JUST as a view, because some of you might start thinking the right way, which would tip the balance because they are the most renowned on OE, I did want to rob THEM from their hilated feeling ONCE THEY SAW THE LIGHT.
Pete, congratulations, you passed the test AND a very important barrier, you opened frontiers, to BOLDLY go, where no one has gone before. OR DID SOMEBODY?
35. Re: SWITCH question
- Posted by petelomax Jan 06, 2018
- 2235 views
There is an additional rule that says the symbols must be different. Within one case you can have two different symbols with the same value:
-- docs say you can have a duplicate value in a case -- if the symbols are different
I must have missed that. Have you got a link?
(I am also saying it should not say that!)
Pete
36. Re: SWITCH question
- Posted by _tom (admin) Jan 06, 2018
- 2208 views
I must have missed that. Have you got a link?
(I am also saying it should not say that!)
Pete
It's not in the 4.0 docs. Now, in the 4.1 docs, I get credit/blame.
That happens to be the observed behavior. So I have to put it into the docs.
Documenting switch is particularily hard because I can't make sense of it.
_tom
37. Re: SWITCH question
- Posted by irv Jan 06, 2018
- 2213 views
I think we you lot need to step back and focus on the C_HANDLE issue as raised in post #2.
...
I will admit that I actually completely missed that C_POINTER and C_HANDLE are in fact the same value!
Pete
Using 64-bit Linux, they're not:
C_POINTER=50331649
C_HANDLE=50331650
38. Re: SWITCH question
- Posted by Ekhnat0n Jan 06, 2018
- 2216 views
Again EXACTLY like it should be, irv, because C_POINTER is giving the offset_value in C_HANDLE (or the other way around if Robert made the pointer_table grow downwards.
C_HANDLE contains a number of Machine-language routine to deal with known errors. With as a last resort the 9/0 for catching Machine_Exceptions, Violations etc, which haven't be solved bij MS yet.
This should be clear to Pete as wwell by now.
39. Re: SWITCH question
- Posted by irv Jan 06, 2018
- 2215 views
Again EXACTLY like it should be, irv, because C_POINTER is giving the offset_value in C_HANDLE (or the other way around if Robert made the pointer_table grow downwards.
C_HANDLE contains a number of Machine-language routine to deal with known errors. With as a last resort the 9/0 for catching Machine_Exceptions, Violations etc, which haven't be solved bij MS yet.
This should be clear to Pete as wwell by now.
Please help me find those machine language routines. Maybe that will help. Which file(s) should I look at?
40. Re: SWITCH question
- Posted by irv Jan 06, 2018
- 2216 views
In be_execute.c, around line 1616 or so, in function analyze_switch():
else if( !IS_ATOM_INT( new_values->base[i] ) || IS_ATOM_INT( second_val ) ){ //c = (0 == compare( new_values->base[i], second_val ) ); -- commenting this out avoids the crash ?
Anyone else want to make that change and recompile, to see if it fixes the sig 11 crash when interpreted?
In addition, see if you can find anything that breaks due to removing it.
-- test case: include std/dll.e switch 1 do case C_HANDLE then case C_POINTER, C_HANDLE then end switch
Former results: A machine-level exception occurred during execution of this statement (signal 11)
Current results: duplicate values in a switch: C_HANDLE and C_HANDLE (which is exactly correct)
Edit: Note, this only handles one source of the sig 11 - there are others, depending upon which test you run. Currently working on those.
41. Re: SWITCH question
- Posted by jimcbrown (admin) Jan 06, 2018
- 2215 views
Again EXACTLY like it should be, irv, because C_POINTER is giving the offset_value in C_HANDLE (or the other way around if Robert made the pointer_table grow downwards.
There's no pointer table, and Rob didn't add C_HANDLE. That was Derek.
http://scm.openeuphoria.org/hg/euphoria/annotate/05dacea121ee/include/std/dll.e#56
C_HANDLE contains a number of Machine-language routine
Please help me find those machine language routines. Maybe that will help. Which file(s) should I look at?
No it doesn't. It's just a constant, there's nothing special behind it.
to deal with known errors. With as a last resort the 9/0 for catching Machine_Exceptions, Violations etc, which haven't be solved bij MS yet.
There is an error handling system in Euphoria that's written in C but it's mostly unrelated to C_HANDLE. Look at be_rterror.c for starters.
42. Re: SWITCH question
- Posted by jimcbrown (admin) Jan 06, 2018
- 2226 views
Brilliant, irv! Good work.
In addition, see if you can find anything that breaks due to removing it.
I haven't tested it, but that looks like it would break the duplicate check when one is comparing strings.
In be_execute.c, around line 1616 or so, in function analyze_switch():
else if( !IS_ATOM_INT( new_values->base[i] ) || IS_ATOM_INT( second_val ) ){ //c = (0 == compare( new_values->base[i], second_val ) ); -- commenting this out avoids the crash ?
I think the real bug is the line above. I think there's a typo with a missing logical not, and the real fix should be:
else if( !IS_ATOM_INT( new_values->base[i] ) || !IS_ATOM_INT( second_val ) ){ c = (0 == compare( new_values->base[i], second_val ) );
If you look at the definition of compare(), in be_runtime.c, you will see this:
object compare(object a, object b) /* Compare general objects a and b. Return 0 if they are identical, 1 if a > b, -1 if a < b. All atoms are less than all sequences. The INT-INT case *must* be taken care of by the caller */
However, the missing 'logical not' after the 'logical or' means that we are sending some INT-INT cases to compare(), which causes a crash (since compare() assumes one of the arguments is a pointer to an internal structure and dereferences accordingly).
43. Re: SWITCH question
- Posted by irv Jan 06, 2018
- 2207 views
You are correct, sir.
Some of the other switch failures seem to come from be_execute.c around line 2030 - specifically when the call to thread() is executed. thread() is defined on line 803:
#define thread() do { __asm { JMP [pc] } } while(0)
Now we are deep into the land of assembly language. Should we abandon all hope?
-- test case: include std/stack.e constant op = stack:new(FIFO) ? op constant stk = 1 ? stk switch stk do -- err line case op then puts(1, "\n result is first stack \n" ) case else puts(1, "\n result is something else \n") end switch
44. Re: SWITCH question
- Posted by jimcbrown (admin) Jan 06, 2018
- 2213 views
Some of the other switch failures seem to come from be_execute.c around line 2030 - specifically when the call to thread() is executed.
Does it still crash if you define INT_CODES? (Look at Makefile.gnu and add -DINT_CODES to EOSFLAGS). By specifying to build the interpreter with INT_CODES you can skip over all this assembly/goto stuff. With INT_CODES, the IL codes are instead processed one at a time, more slowly ... by a big switch statement.
Now we are deep into the land of assembly language. Should we abandon all hope?
I know exactly what this is. Basically, we convert the IL codes into a set of memory addresses, and then we use a goto to jump to the code that handles a particular IL instruction.
thread() is defined on line 803:
#define thread() do { __asm { JMP [pc] } } while(0)
Incidently, this is the wrong one. This definition is only used when compiling against MSVC on Windoze.
This is the one used on Unix/MinGW:
#if defined(EUNIX) || defined(EMINGW) // these GNU-based compilers support dynamic labels, // so threading is much easier #define thread() goto *((void *)*pc) #define thread2() {pc += 2; goto *((void *)*pc);} #define thread4() {pc += 4; goto *((void *)*pc);} #define thread5() {pc += 5; goto *((void *)*pc);} #define inc3pc() pc += 3 #define BREAK goto *((void *)*pc) #endif
45. Re: SWITCH question
- Posted by irv Jan 06, 2018
- 2206 views
The problem is definitely in the thread() function: Running with the added printf lines shown below (starting around line 2022 of be_execute.c:
// threaded code if (Executing == FALSE) { // TODO XXX might this affect exit code improperly? Cleanup(1); return; } printf("E1a\n"); thread(); printf("E1b\n"); switch((intptr_t)pc) {
I get
E1a -- note: this is during first phase (parsing?) 1 -- printed as expected 1 -- ditto E1a -- second parsing (while in switch loop?) /home/irv/t1.ex:9 A machine-level exception occurred during execution of this statement (signal 11)
Notice it goes thru E1a twice. Trying different ways to declare "op" in my test code:
constant op = stack:new(FIFO) -- hits E1a twice, crashing on second encounter. constant op = cos(0) -- hits E1a only once, prior to printing the 1's, then crashes constant op = 1 -- hits E1a only once, prior to printing the 1's, and runs correctly
BTW: adding the -DINT_CODES gave me a world of errors:
46. Re: SWITCH question
- Posted by jimcbrown (admin) Jan 06, 2018
- 2194 views
BTW: adding the -DINT_CODES gave me a world of errors:
/usr/share/euphoria/source/be_execute.c:785:29: error: lvalue required as left operand of assignment
#define thread2() {(long)pc += 2; goto loop_top;}
Hmm, try changing that to this:
#define thread2() do {pc += 2; goto loop_top;} while (0)
You probably will also need to fix thread3, thread4, thread5, and threadpc3
47. Re: SWITCH question
- Posted by irv Jan 07, 2018
- 2156 views
Notice it goes thru E1a twice. Trying different ways to declare "op" in my test code:
constant op = stack:new(FIFO) -- hits E1a twice, crashing on second encounter. constant op = cos(0) -- hits E1a only once, prior to printing the 1's, then crashes constant op = 1 -- hits E1a only once, prior to printing the 1's, and runs correctly
The above leads me to believe that the problem isn't with thread(), but with the caller, which, depending upon which routine is doing the calling, results in either good, bad, or worse results. Probably not putting the correct number of parameters on the stack?
48. Re: SWITCH question
- Posted by Ekhnat0n Jan 07, 2018
- 2183 views
I stand corrected by the facts about the switch-method because I assumed it was an intricate kind of error-handler, whereas it is in fact just a neater way to program nested if..elsif....else...endif constructions, yielding TRUE or FALSE, and reacting to the result of that test.
This, however explains both its erratic behaviour and the fact that there are 2 different values returned. If I take the highest and call that TRUE (it might be the pointer to TRUE as well!) automagically the lower one will be (the maybe pointer to) FALSE. But because it made you end up in the constant-table it is ofc a pointer. Having been too long `off scene` I assumed it still was Eu and not OE, that's why I pointed at RC and not at Derek as its creator.
So the correct use of switch is: Switch (a) ....case (x) ....case (y) ....case (z) default endswitch
BUT NEVER Switch (a) .... case (a) or any condition containing (a) again because (a) has been checked by SWITCH already and will therefore inevitably send a TRUE, followed by the test-result of the next condition.
49. Re: SWITCH question
- Posted by petelomax Jan 07, 2018
- 2117 views
Brilliant, irv! Good work.
we are sending some INT-INT cases to compare(), which causes a crash
That certainly deserves a round of applause. Well done to both of you!
Pete
50. Re: SWITCH question
- Posted by irv Jan 07, 2018
- 2123 views
Unfortunately, that only fixes one problem, and there are at least 2 - probably 3 or more - with switch.
When using a built-in or library routine (for example: cos() or map:new(), etc) the stack is getting corrupted, or the object is being destroyed too soon.
Going to be hard to find, I fear.
51. Re: SWITCH question
- Posted by Ekhnat0n Jan 07, 2018
- 2127 views
cos() is doomed to fail as it will yield a non-integer result lots more often than INTs and the returned value has to be either TRUE or FALSE. What your 2nd example results in, I don't know, but if it isn't either 0 or 1, it will fail also.
52. Re: SWITCH question
- Posted by jimcbrown (admin) Jan 07, 2018
- 2125 views
I stand corrected by the facts about the switch-method because I assumed it was an intricate kind of error-handler, whereas it is in fact just a neater way to program nested if..elsif....else...endif constructions, and reacting to the result of that test.
Yeah, pretty much.
yielding TRUE or FALSE,
The values don't have to be true or false, as the equality test is internal.
This, however explains both its erratic behaviour and the fact that there are 2 different values returned. If I take the highest and call that TRUE (it might be the pointer to TRUE as well!) automagically the lower one will be (the maybe pointer to) FALSE.
Uh, no. That's not how it works.
But because it made you end up in the constant-table it is ofc a pointer.
There isn't a constant-table. (There is a list of symbol names used for error reporting, but that's not the cause of the problem.)
Having been too long `off scene` I assumed it still was Eu and not OE, that's why I pointed at RC and not at Derek as its creator.
OE was scooby's deal.
So the correct use of switch is: Switch (a) ....case (x) ....case (y) ....case (z) default endswitch
BUT NEVER Switch (a) .... case (a) or any condition containing (a) again because (a) has been checked by SWITCH already and will therefore inevitably send a TRUE, followed by the test-result of the next condition.
Actually, as long as a is a literal value or a constant/enum, the second case should be ok!
53. Re: SWITCH question
- Posted by jimcbrown (admin) Jan 07, 2018
- 2126 views
Unfortunately, that only fixes one problem, and there are at least 2 - probably 3 or more - with switch.
When using a built-in or library routine (for example: cos() or map:new(), etc) the stack is getting corrupted, or the object is being destroyed too soon.
Going to be hard to find, I fear.
Agreed.
I'm not sure what's going on with cos(0), but with map:new() and stack:new() we're calling delete_routine() before returning the integer.
So, for complex reasons we're storing this integer value internally as an atom (with the full eu atom struct, etc) just so we can attach the delete_routine routine_id to it. We call this autopromotion.
http://openeuphoria.org/forum/m/121848.wc
The fact that it's an atom on the inside, even though it looks like an integer when you print it out or test it with integer(), is probably what's making it break here.
There's a ticket for this. http://openeuphoria.org/ticket/963.wc
As for cos(), I'm not entirely sure what's going on here, but I do see this in be_runtime.c
object e_cos(object a) /* cos of an angle a (radians) */ { return (object)NewDouble( cos((double)a) ); } object De_cos(d_ptr a) /* double cos of a */ { return (object)NewDouble( cos(a->dbl) ); }
I wonder if it should be calling make_atom() instead of NewDouble? I'm just guessing here but it seems like it might be returning an atom internally always, even if the value can be stored as an integer.
cos() is doomed to fail as it will yield a non-integer result lots more often than INTs and the returned value has to be either TRUE or FALSE.
No, it doesn't. Literal strings are ok, as a counter-example.
What your 2nd example results in, I don't know, but if it isn't either 0 or 1, it will fail also.
Actually, they all are 1.
54. Re: SWITCH question
- Posted by Ekhnat0n Jan 07, 2018
- 2104 views
Comparing literal strings has to be okay, because there can be no confusion about their TYPE, whereas ANY numeric calculation can have either an INT or an ABS as a result. When trying to convert those, weird things WILL HAPPEN, they aren't even 'related'.
55. Re: SWITCH question
- Posted by irv Jan 07, 2018
- 2126 views
FWIW:
I compiled eu.ex (the Euphoria interpreter written in Euphoria, rather than C).
All the switch tests work as expected.
56. aRe: SWITCH question
- Posted by Ekhnat0n Jan 07, 2018
- 2099 views
The reason is that both routines use different methods for it, and they start being UNEQUAL in the truncated part.
57. Re: SWITCH question
- Posted by jimcbrown (admin) Jan 07, 2018
- 2093 views
Comparing literal strings has to be okay, because there can be no confusion about their TYPE, whereas ANY numeric calculation can have either an INT or an ABS as a result. When trying to convert those, weird things WILL HAPPEN, they aren't even 'related'.
No, this should work without issue. There are methods in the C backend to take care of the conversion, so I'm not sure what's going on with switch.
The reason is that both routines use different methods for it, and they start being UNEQUAL in the truncated part.
Actually, make_atom() just calls NewDouble() in some cases.
58. aRe: SWITCH question
- Posted by irv Jan 07, 2018
- 2103 views
The reason is that both routines use different methods for it, and they start being UNEQUAL in the truncated part.
To clarify:
The switch statements which fail do not fail because they can't match the value, they fail because they crash.
Each test has an else... clause where any unequal value would land. It never gets that far.
The crash happens when thread() is called by the function do_exec(). thread() is defined as:
#define thread() goto *((void *)*pc)
See post 55.
59. Re: SWITCH question
- Posted by Ekhnat0n Jan 07, 2018
- 2272 views
And what does it in (ALL-some) cases? Because even if it calls New_Double, it calls it with a value far less precise than New_Double itself can represent!
Once I have my own system going again (major HDD-crash) and both Euphoria and Phix installed again, which was a pain in the southern part of my back, to be honest, I will check every option, including the crashes, because switch ONLY crashes if it is fed with (by switch indigestible) stuff in whatever way.
On top of that, one of my own plans has top-priority right now as it includes creating a channel on youtube and the necessary clips or movies for it, where I do both video & audio myself, including writing the music-score as well and finally record all using my Yamaha-kbd)
60. Re: SWITCH question
- Posted by jimcbrown (admin) Jan 07, 2018
- 2087 views
and what does it in (ALL-some) cases? Because even if it calls New_Double, it calls it with a value far less precise than New_Double itself represents.
Probably fastest to go straight to the source: http://scm.openeuphoria.org/hg/euphoria/file/ba0fec61913e/source/be_runtime.c#l5276
61. Re: SWITCH question
- Posted by irv Jan 07, 2018
- 2130 views
...
I'm not sure what's going on with cos(0), but with map:new() and stack:new() we're calling delete_routine() before returning the integer.
So, for complex reasons we're storing this integer value internally as an atom (with the full eu atom struct, etc) just so we can attach the delete_routine routine_id to it. We call this autopromotion.
http://openeuphoria.org/forum/m/121848.wc
The fact that it's an atom on the inside, even though it looks like an integer when you print it out or test it with integer(), is probably what's making it break here.
There's a ticket for this. http://openeuphoria.org/ticket/963.wc
If the object is deleted, then it's obvious why there is a sig fault. But is there anything that can prevent the deletion? If not, then we just have to live with limited capability for the switch statement, and need to spell that out in the docs.
And secondly, does the eu.ex interpreter also delete the objects, or are they kept around? See post 55
62. Re: SWITCH question
- Posted by Ekhnat0n Jan 07, 2018
- 2140 views
I tried to quote the routine, but it came up with the refarral iso the deconstrution.
5276 object make_atom(uintptr_t c) 5277 /* make a Euphoria atom from an unsigned C value */ 5278 { 5279 if (c <= (uintptr_t)MAXINT) 5280 return c; 5281 else 5282 return NewDouble((eudouble)c); 5283 }
We are dealing with a 32-bit value for MAXINT under certain circumstances and that is a different value from its 64-bit counterpart. But both of them are represented in C in a different way from Euphoria as well, if they are considered to be an INT. Robert used a 31-bit value, with the 32nd bit for ±-indication, C uses the 1 (or 2)-complement method.. I don't exactly remember.. it is (as I said before) a methodical issue as well as all other possible nasties.
63. Re: SWITCH question
- Posted by jimcbrown (admin) Jan 07, 2018
- 2110 views
The fact that it's an atom on the inside, even though it looks like an integer when you print it out or test it with integer(), is probably what's making it break here.
If the object is deleted, then it's obvious why there is a sig fault.
IIUC the object isn't deleted at this point. Rather, it's the fact that the object is an atom - true integers don't seem to be a problem.
And secondly, does the eu.ex interpreter also delete the objects
It has the same functionality, but is limited to a max of 20 delete routines.
64. Re: SWITCH question
- Posted by irv Jan 07, 2018
- 2080 views
IIUC the object isn't deleted at this point. Rather, it's the fact that the object is an atom - true integers don't seem to be a problem.
And secondly, does the eu.ex interpreter also delete the objects
It has the same functionality, but is limited to a max of 20 delete routines.
OK, so why does eu.ex not crash?
65. Re: SWITCH question
- Posted by jimcbrown (admin) Jan 07, 2018
- 2120 views
OK, so why does eu.ex not crash?
It's written in Euphoria, not C, so we don't have to deal with the complexities of managing unions and pointers.
The Euphoria implementation is a lot simpler. For comparision, see http://scm.openeuphoria.org/hg/euphoria/file/ba0fec61913e/source/execute.e#l1639
66. Re: SWITCH question
- Posted by irv Jan 07, 2018
- 2067 views
OK, so why does eu.ex not crash?
It's written in Euphoria, not C, so we don't have to deal with the complexities of managing unions and pointers.
The Euphoria implementation is a lot simpler. For comparision, see http://scm.openeuphoria.org/hg/euphoria/file/ba0fec61913e/source/execute.e#l1639
I understand. What I'm getting at is: is this worth pursuing, or is it basically a lost cause? And if so, is there an earlier version of Eu which has a switch that works in all cases, or has it been broken from the beginning?
67. Re: SWITCH question
- Posted by jimcbrown (admin) Jan 07, 2018
- 2114 views
I understand. What I'm getting at is: is this worth pursuing, or is it basically a lost cause?
It'd be nice if there was someone willing to pursue this. It's a bug that's been around for a while and it would be nice to get it fixed.
Of course, if you think a rewrite is a better option, that's fine too.
And if so, is there an earlier version of Eu which has a switch that works in all cases, or has it been broken from the beginning?
My understanding is that 4.0 works. The code for 4.0 is quite different though, I'm not sure when it changed or why.
http://scm.openeuphoria.org/hg/euphoria/file/ba0723d4b392/source/be_execute.c#l1249
68. Re: SWITCH question
- Posted by irv Jan 07, 2018
- 2098 views
It'd be nice if there was someone willing to pursue this. It's a bug that's been around for a while and it would be nice to get it fixed.
Of course, if you think a rewrite is a better option, that's fine too.
Well, as far as I can tell, the same problems do not exist when I use euc to compile the programs - everything works as advertised.
So, unless a bunch of C gurus show up, maybe I should just add a warning in the docs about this, and suggest compiling if using weird types of switch?