1. SWITCH question

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?

new topic     » topic index » view message » categorize

2. Re: SWITCH question

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?)

new topic     » goto parent     » topic index » view message » categorize

3. Re: SWITCH question

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

new topic     » goto parent     » topic index » view message » categorize

4. Re: SWITCH question

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.

new topic     » goto parent     » topic index » view message » categorize

5. Re: SWITCH question

irv said...

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

new topic     » goto parent     » topic index » view message » categorize

6. Re: SWITCH question

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:

  • Programming since 1968 part professionally but most of the time as a hobby.
  • ZX-Spectrum, Sinclair QL, Atari ST & TT030, lots of Dos/Win-machines
    currently Lenovo G70-80 Linux Ubuntu/Xubuntu 16.04.3 LinuxMint 18.%%
  • Experience in lots of ProgLans in those 49 yrs from 8086 to 68K030 Assembler
new topic     » goto parent     » topic index » view message » categorize

7. Re: SWITCH question

Ekhnat0n said...

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

new topic     » goto parent     » topic index » view message » categorize

8. Re: SWITCH question

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.

new topic     » goto parent     » topic index » view message » categorize

9. Re: SWITCH question

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.

new topic     » goto parent     » topic index » view message » categorize

10. Re: SWITCH question

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.

new topic     » goto parent     » topic index » view message » categorize

11. Re: SWITCH question

Ekhnat0n said...

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

new topic     » goto parent     » topic index » view message » categorize

12. Re: SWITCH question

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?

new topic     » goto parent     » topic index » view message » categorize

13. Re: SWITCH question

jessedavis said...

Go here: http://scm.openeuphoria.org/hg/euphoria/archive/tip.zip

look in execute.e (among other spots) line #1668

Ekhnat0n said...

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).)

irv said...

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.

Ekhnat0n said...

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

Ekhnat0n said...

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.

Ekhnat0n said...

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.

new topic     » goto parent     » topic index » view message » categorize

14. Re: SWITCH question

If I may step in and summarize what has already been said, the thing that is broken is:

The manual should have said...

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

new topic     » goto parent     » topic index » view message » categorize

15. Re: SWITCH question

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)

new topic     » goto parent     » topic index » view message » categorize

16. Re: SWITCH question

petelomax said...

If I may step in and summarize what has already been said, the thing that is broken is:

The manual should have said...

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.

petelomax said...

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.

new topic     » goto parent     » topic index » view message » categorize

17. Re: SWITCH question

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)

new topic     » goto parent     » topic index » view message » categorize

18. Re: SWITCH question

petelomax said...

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

new topic     » goto parent     » topic index » view message » categorize

19. Re: SWITCH question

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.

new topic     » goto parent     » topic index » view message » categorize

20. Re: SWITCH question

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

new topic     » goto parent     » topic index » view message » categorize

21. Re: SWITCH question

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!

new topic     » goto parent     » topic index » view message » categorize

22. Re: SWITCH question

irv said...

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.

irv said...
  • 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.

irv said...

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.

new topic     » goto parent     » topic index » view message » categorize

23. Re: SWITCH question

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.

new topic     » goto parent     » topic index » view message » categorize

24. Re: SWITCH question

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.

new topic     » goto parent     » topic index » view message » categorize

25. Re: SWITCH question

irv said...

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

new topic     » goto parent     » topic index » view message » categorize

26. Re: SWITCH question

Yes, I can confirm that all 3 run properly when compiled.

new topic     » goto parent     » topic index » view message » categorize

27. Re: SWITCH question

irv said...

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

new topic     » goto parent     » topic index » view message » categorize

28. Re: SWITCH question

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

new topic     » goto parent     » topic index » view message » categorize

29. Re: SWITCH question

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.

new topic     » goto parent     » topic index » view message » categorize

30. Re: SWITCH question

irv said...

...

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

new topic     » goto parent     » topic index » view message » categorize

31. Re: SWITCH question

_tom said...

OE functions, built-in and std/lib, are possessed.

_tom

So it appears :(

No wonder some people refuse to use switch.

new topic     » goto parent     » topic index » view message » categorize

32. Re: SWITCH question

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! oops

Pete

new topic     » goto parent     » topic index » view message » categorize

33. Re: SWITCH question

petelomax said...

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

new topic     » goto parent     » topic index » view message » categorize

34. Re: SWITCH question

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?

new topic     » goto parent     » topic index » view message » categorize

35. Re: SWITCH question

_tom said...

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

new topic     » goto parent     » topic index » view message » categorize

36. Re: SWITCH question

petelomax said...

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

new topic     » goto parent     » topic index » view message » categorize

37. Re: SWITCH question

petelomax said...

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! oops

Pete

Using 64-bit Linux, they're not:

C_POINTER=50331649
C_HANDLE=50331650

new topic     » goto parent     » topic index » view message » categorize

38. Re: SWITCH question

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.

new topic     » goto parent     » topic index » view message » categorize

39. Re: SWITCH question

Ekhnat0n said...

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?

new topic     » goto parent     » topic index » view message » categorize

40. Re: SWITCH question

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.

new topic     » goto parent     » topic index » view message » categorize

41. Re: SWITCH question

Ekhnat0n said...

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

irv said...
Ekhnat0n said...

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.

Ekhnat0n said...

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.

new topic     » goto parent     » topic index » view message » categorize

42. Re: SWITCH question

Brilliant, irv! Good work.

irv said...

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.

irv said...

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).

new topic     » goto parent     » topic index » view message » categorize

43. Re: SWITCH question

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 
new topic     » goto parent     » topic index » view message » categorize

44. Re: SWITCH question

irv said...

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.

irv said...

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.

irv said...

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 
new topic     » goto parent     » topic index » view message » categorize

45. Re: SWITCH question

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:

new topic     » goto parent     » topic index » view message » categorize

46. Re: SWITCH question

irv said...

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

new topic     » goto parent     » topic index » view message » categorize

47. Re: SWITCH question

irv said...

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?

new topic     » goto parent     » topic index » view message » categorize

48. Re: SWITCH question

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.

new topic     » goto parent     » topic index » view message » categorize

49. Re: SWITCH question

jimcbrown said...

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

new topic     » goto parent     » topic index » view message » categorize

50. Re: SWITCH question

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.

new topic     » goto parent     » topic index » view message » categorize

51. Re: SWITCH question

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.

new topic     » goto parent     » topic index » view message » categorize

52. Re: SWITCH question

Ekhnat0n said...

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.

Ekhnat0n said...

yielding TRUE or FALSE,

The values don't have to be true or false, as the equality test is internal.

Ekhnat0n said...

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.

Ekhnat0n said...

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.)

Ekhnat0n said...

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.

Ekhnat0n said...

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!

new topic     » goto parent     » topic index » view message » categorize

53. Re: SWITCH question

irv said...

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.

Ekhnat0n said...

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.

Ekhnat0n said...

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.

new topic     » goto parent     » topic index » view message » categorize

54. Re: SWITCH question

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'.

new topic     » goto parent     » topic index » view message » categorize

55. Re: SWITCH question

FWIW:

I compiled eu.ex (the Euphoria interpreter written in Euphoria, rather than C).

All the switch tests work as expected.

new topic     » goto parent     » topic index » view message » categorize

56. aRe: SWITCH question

The reason is that both routines use different methods for it, and they start being UNEQUAL in the truncated part.

new topic     » goto parent     » topic index » view message » categorize

57. Re: SWITCH question

Ekhnat0n said...

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.

Ekhnat0n said...

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.

new topic     » goto parent     » topic index » view message » categorize

58. aRe: SWITCH question

Ekhnat0n said...

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.

new topic     » goto parent     » topic index » view message » categorize

59. Re: SWITCH question

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)

new topic     » goto parent     » topic index » view message » categorize

60. Re: SWITCH question

Ekhnat0n said...

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

new topic     » goto parent     » topic index » view message » categorize

61. Re: SWITCH question

jimcbrown said...

...

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

new topic     » goto parent     » topic index » view message » categorize

62. Re: SWITCH question

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.

new topic     » goto parent     » topic index » view message » categorize

63. Re: SWITCH question

irv said...
jimcbrown said...

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.

irv said...

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.

new topic     » goto parent     » topic index » view message » categorize

64. Re: SWITCH question

jimcbrown said...

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.

irv said...

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?

new topic     » goto parent     » topic index » view message » categorize

65. Re: SWITCH question

irv said...

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

new topic     » goto parent     » topic index » view message » categorize

66. Re: SWITCH question

jimcbrown said...
irv said...

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?

new topic     » goto parent     » topic index » view message » categorize

67. Re: SWITCH question

irv said...

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.

irv said...

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

new topic     » goto parent     » topic index » view message » categorize

68. Re: SWITCH question

jimcbrown said...

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?

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu