1. Rob: More trouble with PD-source
- Posted by Vincent <darkvincentdude at yahoo.com>
Nov 26, 2005
-
Last edited Nov 27, 2005
Rob,
I hate to bring up more stuff but check out NetRadio.exw! When I run it with the
official interpreter, it's fine. But wait until you try it with the PD-source
interpreted and translated/compiled (Borland and Watcom).
I can't believe whats happening.
Random errors !?!
I click one button, I get a subscript error; click another, I get a type check
error; another, a "true/false condition must be an ATOM"; another, machine-level
exception; another, plays a streaming broadcast; another, a "c_proc/c_func:
argument list must be a sequence"; another, "subscript value out of bounds";
another, a Win32Lib error; another, program crash with no error!! I think the
errors vary whether I run it with interpreted source or a translated/compiled
interpreter.
Again, none of this seems to happen with the official RDS interpreter.
Could this all be caused by the bug just reported and/or other known bugs?
Regards,
Vincent
2. Re: Rob: More trouble with PD-source
- Posted by Eucoder <eucoder at hotmail.com>
Nov 26, 2005
-
Last edited Nov 27, 2005
Hum... I have never seen random errors like that before, and I do not think it
is the same bug.
>
> I hate to bring up more stuff but check out NetRadio.exw! When I run it with
> the official interpreter, it's fine. But wait until you try it with the
> PD-source
> interpreted and translated/compiled (Borland and Watcom).
> I can't believe whats happening.
>
3. Re: Rob: More trouble with PD-source
- Posted by Robert Craig <rds at RapidEuphoria.com>
Nov 26, 2005
-
Last edited Nov 27, 2005
Vincent wrote:
> I hate to bring up more stuff but check out NetRadio.exw! When I run it with
> the official interpreter, it's fine. But wait until you try it with the
> PD-source
> interpreted and translated/compiled (Borland and Watcom).
> I can't believe whats happening.
>
> Random errors !?!
>
> I click one button, I get a subscript error; click another, I get a type check
> error; another, a "true/false condition must be an ATOM"; another,
> machine-level
> exception; another, plays a streaming broadcast; another, a "c_proc/c_func:
> argument list must be a sequence"; another, "subscript value out of bounds";
> another, a Win32Lib error; another, program crash with no error!! I think the
> errors vary whether I run it with interpreted source or a translated/compiled
> interpreter.
>
> Again, none of this seems to happen with the official RDS interpreter.
>
> Could this all be caused by the bug just reported and/or other known bugs?
It might all be due to the initial bug in the PD source.
I won't know until I fix that bug.
He is using fractional subscripts and they aren't
handled properly by the PD source.
I'll test his other programs too, after I fix the
initial bug.
If something doesn't run correctly with "exw eu.ex",
there is no point in translating/compiling eu.ex. That
will just remove error checks, and make error messages
happen more remotely from the actual problem, and
probably seem more bizarre.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
4. Re: Rob: More trouble with PD-source
Robert Craig wrote:
> Vincent wrote:
> > I hate to bring up more stuff but check out NetRadio.exw! When I run it with
> > the official interpreter, it's fine. But wait until you try it with the
> > PD-source
> > interpreted and translated/compiled (Borland and Watcom).
> > I can't believe whats happening.
> >
> > Random errors !?!
> >
> > I click one button, I get a subscript error; click another, I get a type
> > check
> > error; another, a "true/false condition must be an ATOM"; another,
> > machine-level
> > exception; another, plays a streaming broadcast; another, a "c_proc/c_func:
> > argument list must be a sequence"; another, "subscript value out of bounds";
> > another, a Win32Lib error; another, program crash with no error!! I think
> > the
> > errors vary whether I run it with interpreted source or a
> > translated/compiled
> > interpreter.
> >
> > Again, none of this seems to happen with the official RDS interpreter.
> >
> > Could this all be caused by the bug just reported and/or other known bugs?
>
> It might all be due to the initial bug in the PD source.
> I won't know until I fix that bug.
> He is using fractional subscripts and they aren't
> handled properly by the PD source.
> I'll test his other programs too, after I fix the
> initial bug.
I looked into this some more.
The PD source had a couple of places
where it was not handling fractional subscripts,
but in the simple, common cases it was actually
handling them ok.
That didn't fix all the Bass programs though.
Some still don't work with the PD source.
I then changed all the Bass library routines to be CDECL
by adding a "+" to the names. That didn't seem to make
any difference.
I now have the impression that the PD source might be failing,
simply because it executes too slow. If I turn on "with trace"
and trace(3), and run using exw.exe, it also crashes in a weird way.
If I remove the frequent callback to StatusProc(), the PD source
runs netradio.exw ok. I wonder if there is a high-speed
stream of callbacks coming in, that the PD source, or even
exw (using trace(3)) can't keep up with. Maybe Elliott has an idea.
His documentation suggests that these callbacks should be handled quickly.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
5. Re: Rob: More trouble with PD-source
Hello Robert,
The project I am working on also has a weird bug, and it happens with the
RDS version of EU. It's a callback that executes when a connection is lost.
When it executes it closes the app without an error, but if I compile the app
to C it works fine. I will try and strip it down to a simple example so you
can run a test. I run into bugs all the time, but I always find alternative
solutions so I never report them. I guess from now I will report bugs I come
across.
As for the bug you mentioned, even if you compile the example to C you will get
the error. I do not think it is a speed issue, I think it is a bug with EU that
does not appear in the RDS version because C just ignores the bug/and or handles
it more gracefully.
6. Re: Rob: More trouble with PD-source
My CPU goes into 100% usage when I visit Elliot's site on
http://wingzone.tripod.com/bass.htm#bass
and I have to close down IEXPLORE.EXE to recover.
Any connection?
Regards,
Bob
7. Re: Rob: More trouble with PD-source
I managed to get access to Elliott's site eventually but Ctrl refresh
got the problem back on one attempt after connecting from the contributor
page link.
Just got CHKDSK deleting a corrupt file record segment on restart.
I caught the number 49154 and the name ampl.spc. before it finished.
Is this a problem at my end?
Regards,
Bob
8. Re: Rob: More trouble with PD-source
Bob Thompson wrote:
>
> I managed to get access to Elliott's site eventually but Ctrl refresh
> got the problem back on one attempt after connecting from the contributor
> page link.
>
I am not sure what would cause this. There are no client-side scripts on my
site that I recall. Perhaps it is a tripod ad script or something. Of course, it
could be that beast of a thing called Internet Explorer.
> Just got CHKDSK deleting a corrupt file record segment on restart.
> I caught the number 49154 and the name ampl.spc. before it finished.
>
The file name does not seem to relate to anything on the website or even
anything that would be saved in the cache.
> Is this a problem at my end?
>
> Regards,
>
> Bob
~[ WingZone ]~
http://wingzone.tripod.com/
9. Re: Rob: More trouble with PD-source
Robert Craig wrote:
>
> Robert Craig wrote:
> >
> > It might all be due to the initial bug in the PD source.
> > I won't know until I fix that bug.
> > He is using fractional subscripts and they aren't
> > handled properly by the PD source.
> > I'll test his other programs too, after I fix the
> > initial bug.
>
I have updated the examples to use floor() in as many places as I could find
that needed it. It should minimize any of these errors. All cases are not
completely fixed, though. I should be able to upload the new files tonight.
> I looked into this some more.
> The PD source had a couple of places
> where it was not handling fractional subscripts,
> but in the simple, common cases it was actually
> handling them ok.
>
> That didn't fix all the Bass programs though.
> Some still don't work with the PD source.
>
> I then changed all the Bass library routines to be CDECL
> by adding a "+" to the names. That didn't seem to make
> any difference.
>
All functions are declared WINAPI; they should be defined stdcall. Those other
three were flukes I tell you. Honest. :P
> I now have the impression that the PD source might be failing,
> simply because it executes too slow. If I turn on "with trace"
> and trace(3), and run using exw.exe, it also crashes in a weird way.
> If I remove the frequent callback to StatusProc(), the PD source
> runs netradio.exw ok. I wonder if there is a high-speed
> stream of callbacks coming in, that the PD source, or even
> exw (using trace(3)) can't keep up with. Maybe Elliott has an idea.
> His documentation suggests that these callbacks should be handled quickly.
>
I can confirm that without the StatusProc, the example does work correctly.
Speed is somewhat important in these cases since audio buffering is involved. The
DSPTest, for example, is machine-staggeringly slow when run through the PD
source. Still, it is able to run without crashing, albeit quite slowly. However,
I do not think speed is as important in the StatusProc since it is meant for
saving downloaded data.
It may well be that Eu's lack of thread-safety is the cause of this problem.
However, I do not know why it would still work with the official interpreter. The
errors are quite random. Sometimes, only half an error message is printed,
without the actual error showing up, even in the ex.err file. This is sometimes a
sign of the problem with thread-safety, but I cannot confirm it.
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
~[ WingZone ]~
http://wingzone.tripod.com/
10. Re: Rob: More trouble with PD-source
Hello Elliott,
The deleted spec file belonged to Crimson Editor
and would have read like this before corruption;
# AMPL LANGUAGE KEYWORDS FILE FOR CRIMSON EDITOR
# 23.01.2003, Stuart Thorncraft
$CASESENSITIVE=YES
$DELIMITERS=~!@$%^*()+=\|&{}[]:;"'<> , ?
$QUOTATIONMARK1="
$QUOTATIONMARK2='
$LINECOMMENT=#
$PAIRS1=()
$PAIRS2=[]
$PAIRS3={}
Maybe all coincidence. I'll re-visit your site later :)
Regards,
Bob
11. Re: Rob: More trouble with PD-source
Elliott Sales de Andrade wrote:
> I can confirm that without the StatusProc, the example does work correctly.
> Speed is somewhat important in these cases since audio buffering is involved.
> The DSPTest, for example, is machine-staggeringly slow when run through the
> PD source. Still, it is able to run without crashing, albeit quite slowly.
> However,
> I do not think speed is as important in the StatusProc since it is meant for
> saving downloaded data.
I just tried a little experiment with NetRadio.exw.
If I add a small delay:
for i = 1 to 1000 do
end for
before returning from the callback, exw runs NetRadio ok.
But if I increase the loop to 10,000 ... 100,000 ... 1,000,000
then things become unstable, and eventually it crashes with
one of those weird errors. So there is a problem if the callback
takes too long, and maybe also if other processing takes too long.
I'm guessing the PD source (exw eu.ex) is too slow for certain
demanding operations. It doesn't crash when it's simply displaying
a GUI. It's when some data is being transferred at high-speed.
I think your BASS stuff is requiring a minimum level of speed.
> It may well be that Eu's lack of thread-safety is the cause of this problem.
> However, I do not know why it would still work with the official interpreter.
> The errors are quite random. Sometimes, only half an error message is printed,
> without the actual error showing up, even in the ex.err file. This is
> sometimes
> a sign of the problem with thread-safety, but I cannot confirm it.
If you run multiple threads in a non-thread-safe environment,
corruption can happen. For example, if two threads are
allocating space from the same heap at the same time, the
heap could get corrupted and all hell could break loose,
causing the interpreter to behave in a totally insane way.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
12. Re: Rob: More trouble with PD-source
Robert Craig wrote:
<snip>
> If you run multiple threads in a non-thread-safe environment,
> corruption can happen. For example, if two threads are
> allocating space from the same heap at the same time, the
> heap could get corrupted and all hell could break loose,
> causing the interpreter to behave in a totally insane way.
Will Eu 2.6 be thread-safe?
Regards,
Juergen
--
Have you read a good program lately?
13. Re: Rob: More trouble with PD-source
Robert Craig wrote:
>
> Elliott Sales de Andrade wrote:
> > I can confirm that without the StatusProc, the example does work correctly.
> > Speed is somewhat important in these cases since audio buffering is
> > involved.
> > The DSPTest, for example, is machine-staggeringly slow when run through the
> > PD source. Still, it is able to run without crashing, albeit quite slowly.
> > However,
> > I do not think speed is as important in the StatusProc since it is meant for
> > saving downloaded data.
>
> I just tried a little experiment with NetRadio.exw.
> If I add a small delay:
> for i = 1 to 1000 do
> end for
> before returning from the callback, exw runs NetRadio ok.
> But if I increase the loop to 10,000 ... 100,000 ... 1,000,000
> then things become unstable, and eventually it crashes with
> one of those weird errors. So there is a problem if the callback
> takes too long, and maybe also if other processing takes too long.
> I'm guessing the PD source (exw eu.ex) is too slow for certain
> demanding operations. It doesn't crash when it's simply displaying
> a GUI. It's when some data is being transferred at high-speed.
> I think your BASS stuff is requiring a minimum level of speed.
>
It crashes with different random errors each time I click a button in
NetRadio.exw, with EXW and trace(3).
Can you do anything about this?
> > It may well be that Eu's lack of thread-safety is the cause of this problem.
> > However, I do not know why it would still work with the official
> > interpreter.
> > The errors are quite random. Sometimes, only half an error message is
> > printed,
> > without the actual error showing up, even in the ex.err file. This is
> > sometimes
> > a sign of the problem with thread-safety, but I cannot confirm it.
>
> If you run multiple threads in a non-thread-safe environment,
> corruption can happen. For example, if two threads are
> allocating space from the same heap at the same time, the
> heap could get corrupted and all hell could break loose,
> causing the interpreter to behave in a totally insane way.
>
Elliott could probably use TDLL in these cases. A Linux and BSD port of this
library would be nice.
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
Regards,
Vincent
14. Re: Rob: More trouble with PD-source
- Posted by Vincent <darkvincentdude at yahoo.com>
Nov 29, 2005
-
Last edited Nov 30, 2005
Juergen Luethje wrote:
> Will Eu 2.6 be thread-safe?
No, but we'll get it eventually, along with 64 bit support and a Mac port.
If we do not have at least the first two someday, Euphoria would place itself at
an enormous disadvantage against almost any other successful language.
Regards,
Vincent
15. Re: Rob: More trouble with PD-source
- Posted by Robert Craig <rds at RapidEuphoria.com>
Nov 29, 2005
-
Last edited Nov 30, 2005
Vincent wrote:
> Robert Craig wrote:
> > I just tried a little experiment with NetRadio.exw.
> > If I add a small delay:
> > for i = 1 to 1000 do
> > end for
> > before returning from the callback, exw runs NetRadio ok.
> > But if I increase the loop to 10,000 ... 100,000 ... 1,000,000
> > then things become unstable, and eventually it crashes with
> > one of those weird errors. So there is a problem if the callback
> > takes too long, and maybe also if other processing takes too long.
> > I'm guessing the PD source (exw eu.ex) is too slow for certain
> > demanding operations. It doesn't crash when it's simply displaying
> > a GUI. It's when some data is being transferred at high-speed.
> > I think your BASS stuff is requiring a minimum level of speed.
> >
>
> It crashes with different random errors each time I click a button in
> NetRadio.exw,
> with EXW and trace(3).
>
> Can you do anything about this?
No I can't. That's my point. The application seems to
require a certain minimum level of speed from the
interpreter. exw is fast enough. But the instant you
turn on trace(3), it will start writing (and flushing)
a line of text to a file for every single statement
that it executes. That slows exw down by at least a
couple of orders of magnitude, and makes it even
slower than "exw eu.ex", which we know is too slow.
Exactly why it crashes, we don't know, but it could
have something to do with running multiple O/S threads,
something that isn't really supported by Euphoria
(as you are well aware 
).
By the way, I won two games of Language War last night
using multi *tasking* in the official ex.exe (C backend) interpreter.
So that project is coming along well. Maybe I'll release something
in a week or so.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
16. Re: Rob: More trouble with PD-source
- Posted by Vincent <darkvincentdude at yahoo.com>
Nov 29, 2005
-
Last edited Nov 30, 2005
Robert Craig wrote:
> No I can't. That's my point. The application seems to
> require a certain minimum level of speed from the
> interpreter. exw is fast enough. But the instant you
> turn on trace(3), it will start writing (and flushing)
> a line of text to a file for every single statement
> that it executes. That slows exw down by at least a
> couple of orders of magnitude, and makes it even
> slower than "exw eu.ex", which we know is too slow.
> Exactly why it crashes, we don't know, but it could
> have something to do with running multiple O/S threads,
> something that isn't really supported by Euphoria
> (as you are well aware ).
Hmm... why does this code work with EXW + trace(3) and "exw eu netradio" +
trace(3)?:
StatusProc = routine_id("StatusProc")
chan = BASS_StreamCreateURL(urls[event], 0, BASS_STREAM_STATUS, StatusProc, 0)
but not this:
chan = BASS_StreamCreateURL(urls[event], 0, BASS_STREAM_STATUS,
routine_id("StatusProc"), 0)
Eu has to assign "StatusProc" before "chan" with each consecutive call to the
"DialogProc" subroutine, right? How would this be so different?
> By the way, I won two games of Language War last night
> using multi *tasking* in the official ex.exe (C backend) interpreter.
> So that project is coming along well. Maybe I'll release something
> in a week or so.
Kewl... are you planning to offer the gameplay recording feature too?
BTW, Open Watcom 1.4 is at it's second release candidate. It should be released
in time for Eu 3.0 building; perhaps you then can remove or comment out all the
Watcom 10.6 bug workaround code, that might be hindering back-end performance and
efficency a bit? Did you consider sacrificing a bit more memory for better
recursive performance with single task applications/libraries?
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
Regards,
Vincent
17. Re: Rob: More trouble with PD-source
Vincent wrote:
> Hmm... why does this code work with EXW + trace(3) and "exw eu netradio" +
> trace(3)?:
> }}}
<eucode>
> StatusProc = routine_id("StatusProc")
> chan = BASS_StreamCreateURL(urls[event], 0, BASS_STREAM_STATUS, StatusProc, 0)
> </eucode>
{{{
> but not this:
> }}}
<eucode>
> chan = BASS_StreamCreateURL(urls[event], 0, BASS_STREAM_STATUS,
> routine_id("StatusProc"), 0)
> </eucode>
{{{
> Eu has to assign "StatusProc" before "chan" with each consecutive call to the
> "DialogProc" subroutine, right? How would this be so different?
By defining a private variable "StatusProc", you are causing
the routine id of "StatusProc" to be -1. This turns off the
(frequent) callback to StatusProc(), so things work much better.
I think I mentioned already that things worked much better
when that callback was turned off.
> > By the way, I won two games of Language War last night
> > using multi *tasking* in the official ex.exe (C backend) interpreter.
> > So that project is coming along well. Maybe I'll release something
> > in a week or so.
>
> Kewl... are you planning to offer the gameplay recording feature too?
Yes. The video capture option doesn't consume much time.
You can't even tell it's runnning. A time-shared
task writes frames of data to disk when there's nothing else to do.
A profile_time on Language War shows that about 90% of the time it's just
sitting in the scheduler waiting for the clock to advance so
it can run the next task.
> BTW, Open Watcom 1.4 is at it's second release candidate. It should be
> released
> in time for Eu 3.0 building; perhaps you then can remove or comment out all
> the Watcom 10.6 bug workaround code, that might be hindering back-end
> performance
> and efficency a bit?
I hope so. There are a few places where I lose a tiny bit of
performance in order to work around a Watcom bug.
> Did you consider sacrificing a bit more memory for better
> recursive performance with single task applications/libraries?
Yes, I'll probably do that.
I want to make sure everything is rock solid before
I start inserting small optimizations.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
18. Re: Rob: More trouble with PD-source
Robert Craig wrote:
> By defining a private variable "StatusProc", you are causing
> the routine id of "StatusProc" to be -1. This turns off the
> (frequent) callback to StatusProc(), so things work much better.
> I think I mentioned already that things worked much better
> when that callback was turned off.
OK thanks, I think I understand now.
> Yes. The video capture option doesn't consume much time.
> You can't even tell it's runnning. A time-shared
> task writes frames of data to disk when there's nothing else to do.
> A profile_time on Language War shows that about 90% of the time it's just
> sitting in the scheduler waiting for the clock to advance so
> it can run the next task.
Right have it as an *option*, we wouldnt want to use it all the time. It can
create huge playback files to disk.
> I hope so. There are a few places where I lose a tiny bit of
> performance in order to work around a Watcom bug.
Right.
> Yes, I'll probably do that.
> I want to make sure everything is rock solid before
> I start inserting small optimizations.
Fantastic... sounds great. Later when it's time to implement real thread-safety
and extend + modify the existing task API, you'd probably have to make some
significant changes to the existing code; perhaps that would eliminate this
problem all together.
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
Regards,
Vincent
