1. 2.4 problems
Hello,
Another keyword Borland doesn't like: "asm"
Used as a variable name in fptr.e, Borland won't compile the translated
code.
I'm also having another problem with 2.4 with memory allocation or
possibly with sequence concatenation. Haven't nailed it down yet, but
in certain circumstances when using the "compress()" function in
database.e my program comes to a dead halt. (I'm not actually using
database.e or EDS -- I stole the function to use for other things.) It
hasn't really stopped completely, but it goes really slow (suddenly) and
takes forever to return from the function (like many minutes for what
should take a fraction of a second). Doesn't do it in 2.3. As yet, I'm
unable to reproduce the problem with a simple example. The strange
thing is, it doesn't slow down until I've already called the function
successfully a few dozen times previously in the program. Anyway, I
still think there are issues there somewhere.
It acts the same way translated with either Watcom or Borland -- I got
the impression that Borland does not use the new allocator? So maybe
the problem lies with your changes to the "&" operator? You might want
to look it over as I may not be able to isolate this...
2. Re: 2.4 problems
Andy Serpa wrote:
> Another keyword Borland doesn't like: "asm"
>
> Used as a variable name in fptr.e, Borland won't compile the translated
> code.
Yes, I've got that one on my exclusion list
for the 2.4 official Translator release.
> I'm also having another problem with 2.4 with memory allocation or
> possibly with sequence concatenation. Haven't nailed it down yet, but
> in certain circumstances when using the "compress()" function in
> database.e my program comes to a dead halt. (I'm not actually using
> database.e or EDS -- I stole the function to use for other things.) It
> hasn't really stopped completely, but it goes really slow (suddenly) and
> takes forever to return from the function (like many minutes for what
> should take a fraction of a second). Doesn't do it in 2.3. As yet, I'm
> unable to reproduce the problem with a simple example. The strange
> thing is, it doesn't slow down until I've already called the function
> successfully a few dozen times previously in the program. Anyway, I
> still think there are issues there somewhere.
>
> It acts the same way translated with either Watcom or Borland -- I got
> the impression that Borland does not use the new allocator?
Watcom, Borland and Lcc all use the Windows default heap now,
and they all allocate/deallocate space in the same way.
> So maybe the problem lies with your changes to the "&" operator?
> You might want to look it over as I may not be able to isolate this...
I hope you can narrow it down. I don't know of any other
performance bugs like this in 2.4 beta, except for one that
can only happen if you use a Euphoria-written .dll
(reported by Euman, that bug has been fixed for the official release).
Be careful that you are running 2.4 beta, not alpha.
Thanks,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: 2.4 problems
Andy Serpa wrote:
> The following rather strange program seems to do the trick:
Thanks for the example.
It runs fine on my 256MB XP system,
but on my 64Mb ME system it stalls for an
extremely long time on: s3 = {}
I'll try to figure out what's happening.
Probably the storage allocation/deallocation
algorithm needs to be tweaked to handle this
extreme case.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
4. Re: 2.4 problems
On Mon, 9 Jun 2003 16:18:42 +0000, Andy Serpa <ac at onehorseshy.com>
wrote:
<snip>
>for i =3D 1 to 500000 do
^ i had to kill a zero on that ;-( {P233, 48MB, Eu 2.4 beta}
>--s1 =3D {}
^^^ bizarre!!!=20
Correct me if I'm wrong, but that is a top-level statement executed
exactly ONCE (when uncommented 
)
Bizzare, because variable s1 is not referenced *at all* after that
point (I'm measuring just up to the --s2 =3D {} line, no further).
Andy, Rob, just that *one* line uncomment made it run like a dog (TEN
times slower: 130 seconds vs 13 seconds) on my PC.
Bizzare, because code *NOT* referencing that variable, like I just
said, runs ten times slower!!
Andy: I think you have definitely found something 
.
Pete
