1. wxEuphoria on FreeBSD
I've managed to get wxEuphoria working on FreeBSD 6.2 (note that the
stock euphoria interpreter doesn't work out of the box* on FreeBSD 6.2).
Not sure how many people out there are using FreeBSD, but you can now use
wxEuphoria there. Check out the source from svn for now. I'll do a real
release when I put up the betas for v0.10.0. Take a look at readme.txt,
which has build instructions for all 3 platforms.
Matt
* It seems that some system libraries have been changed or moved. By
creating a couple of symlinks, it seemed to work. I was also able to
build it from source after modifying the Linux makefile, plus a minor
change to the source (matherr was already defined, so I added an ifdef
to keep it out). I'll probably check it into svn sometime this weekend.
2. Re: wxEuphoria on FreeBSD
Matt Lewis wrote:
> I've managed to get wxEuphoria working on FreeBSD 6.2 (note that the
> stock euphoria interpreter doesn't work out of the box* on FreeBSD 6.2).
>
> Not sure how many people out there are using FreeBSD, but you can now use
> wxEuphoria there. Check out the source from svn for now. I'll do a real
> release when I put up the betas for v0.10.0. Take a look at readme.txt,
> which has build instructions for all 3 platforms.
>
> Matt
>
> * It seems that some system libraries have been changed or moved. By
> creating a couple of symlinks, it seemed to work. I was also able to
> build it from source after modifying the Linux makefile, plus a minor
> change to the source (matherr was already defined, so I added an ifdef
> to keep it out). I'll probably check it into svn sometime this weekend.
Thanks.
I've personally only tested Euphoria for FreeBSD on
the RapidEuphoria.com server, via Telnet, or for CGI
programming. RapidEuphoria.com is currently
running FreeBSD 4.10 STABLE. Others have run it successfully
on their various FreeBSD systems.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: wxEuphoria on FreeBSD
- Posted by Matt Lewis <matthewwalkerlewis at gmail.com>
Mar 30, 2007
-
Last edited Mar 31, 2007
Robert Craig wrote:
>
> Thanks.
> I've personally only tested Euphoria for FreeBSD on
> the RapidEuphoria.com server, via Telnet, or for CGI
> programming. RapidEuphoria.com is currently
> running FreeBSD 4.10 STABLE. Others have run it successfully
> on their various FreeBSD systems.
Erg. Ran a complex program and started getting random crashes. So I
fired up valgrind. It really doesn't like when you check for MAGIC_FILLER
to see if the block was really 8-aligned, and it turns out it was, and
you just did an invalid read.
Oh, but wait...according to your comments, you assume that it's always
8-aligned for BSD, which was apparently true, but since v4, they've
reworked their malloc implementation, so that's not guaranteed anymore.
And they just put posix_memalign into v7 (which was why I was having
to let it check for alignment in the first place).
After banging my head for a while, I've come to the conclusion that the
simplest way to get this to work is to just always malloc 8 more bytes
than asked for, and put MAGIC_FILLER in for a 4 byte alligned chunk,
and a 0 in for an 8 byte alignment. Of course, I'll have to memcopy
in realloc if we switch alignments.
Anywho, just had to rant a bit to clear my head...BSD port may take longer
than expected....
Matt
4. Re: wxEuphoria on FreeBSD
- Posted by Robert Craig <rds at RapidEuphoria.com>
Mar 30, 2007
-
Last edited Mar 31, 2007
Matt Lewis wrote:
>
> Robert Craig wrote:
> >
> > Thanks.
> > I've personally only tested Euphoria for FreeBSD on
> > the RapidEuphoria.com server, via Telnet, or for CGI
> > programming. RapidEuphoria.com is currently
> > running FreeBSD 4.10 STABLE. Others have run it successfully
> > on their various FreeBSD systems.
>
> Erg. Ran a complex program and started getting random crashes. So I
> fired up valgrind. It really doesn't like when you check for MAGIC_FILLER
> to see if the block was really 8-aligned, and it turns out it was, and
> you just did an invalid read.
>
> Oh, but wait...according to your comments, you assume that it's always
> 8-aligned for BSD, which was apparently true, but since v4, they've
> reworked their malloc implementation, so that's not guaranteed anymore.
> And they just put posix_memalign into v7 (which was why I was having
> to let it check for alignment in the first place).
The dirty assumptions that I make about malloc() have always
been a problem when porting.
> After banging my head for a while, I've come to the conclusion that the
> simplest way to get this to work is to just always malloc 8 more bytes
> than asked for, and put MAGIC_FILLER in for a 4 byte alligned chunk,
> and a 0 in for an 8 byte alignment. Of course, I'll have to memcopy
> in realloc if we switch alignments.
Good idea. Just get it working cleanly. We can worry about
saving memory later.
> Anywho, just had to rant a bit to clear my head...BSD port may take longer
> than expected....
Subtle malloc bugs can be nightmarishly difficult to track down.
I'm impressed that you've figured out this much.
I hope you don't blame me for your torture. 
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
5. Re: wxEuphoria on FreeBSD
Robert Craig wrote:
>
> The dirty assumptions that I make about malloc() have always
> been a problem when porting.
Yeah, I've been working on linux for a bit now, and I've discovered that
(at least for FC6--not sure what version of libc that has) if you realloc
smaller, and it gives you the same pointer back, malloc_usable_size()
gives you the old answer, causing you to make invalid writes to memory.
> > After banging my head for a while, I've come to the conclusion that the
> > simplest way to get this to work is to just always malloc 8 more bytes
> > than asked for, and put MAGIC_FILLER in for a 4 byte alligned chunk,
> > and a 0 in for an 8 byte alignment. Of course, I'll have to memcopy
> > in realloc if we switch alignments.
>
> Good idea. Just get it working cleanly. We can worry about
> saving memory later.
I haven't even really attempted to figure out what you do with all the
cache and pool junk in there.
> Subtle malloc bugs can be nightmarishly difficult to track down.
> I'm impressed that you've figured out this much.
> I hope you don't blame me for your torture.
No, not really. Of course, a big issue is the rate of change in free and
open source operating systems. I generally enjoy digging and digging until
I figure out this sort of thing. I must say, valgrind really helps,
especially when you remember to turn on debugging symbols (slaps head).
Matt
6. Re: wxEuphoria on FreeBSD
Matt Lewis wrote:
> I haven't even really attempted to figure out what you do with all the
> cache and pool junk in there.
Originally (many years ago, pre-1.0) I just made direct calls
to malloc() and free(), but profiling showed that malloc()/free()
was consuming a fair bit of time, so I added the "storage cache" idea.
I created about 14(?) linked lists of standardized block sizes, up to
a certain large (and uncommon) size. "free" just links a block onto
the appropriate-sized list, while "allocate" normally just grabs
the first item on the list. These operations are very fast,
just a few machine instructions. This is also efficient for
accesses to the CPU data cache, since the most recently freed block
is the first to be reused. I found there are often loops where the
same sized blocks are allocated and freed over and over.
This speeds things up, and quite often eliminates virtually all
calls to malloc/free inside a loop. However, I don't think this
is a huge win, as implementations of malloc have improved over
the years, and in fact they sometimes implement something very
similar to what I did. Also, there is an issue of having a whole
bunch of freed blocks of a certain size when the demand shifts
to blocks of a different size. A mechanism is in place to
deal with this.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
7. Re: wxEuphoria on FreeBSD
Robert Craig wrote:
>
> Matt Lewis wrote:
> > I haven't even really attempted to figure out what you do with all the
> > cache and pool junk in there.
>
> Originally (many years ago, pre-1.0) I just made direct calls
> to malloc() and free(), but profiling showed that malloc()/free()
> was consuming a fair bit of time, so I added the "storage cache" idea.
>
> I created about 14(?) linked lists of standardized block sizes, up to
> a certain large (and uncommon) size. "free" just links a block onto
> the appropriate-sized list, while "allocate" normally just grabs
> the first item on the list. These operations are very fast,
> just a few machine instructions. This is also efficient for
> accesses to the CPU data cache, since the most recently freed block
> is the first to be reused. I found there are often loops where the
> same sized blocks are allocated and freed over and over.
OK, that sheds some light on what I've been seeing. When I go
straight to malloc, there's no problem. But Linux and FreeBSD don't
like things like memcopy to write or read in blocks that overlap
different mallocs.
> This speeds things up, and quite often eliminates virtually all
> calls to malloc/free inside a loop. However, I don't think this
> is a huge win, as implementations of malloc have improved over
> the years, and in fact they sometimes implement something very
> similar to what I did. Also, there is an issue of having a whole
> bunch of freed blocks of a certain size when the demand shifts
> to blocks of a different size. A mechanism is in place to
> deal with this.
For now, as mentioned above, I'm making the direct malloc/realloc/free
calls for linux and bsd (I've written, but not tested the alignment
code for bsd). The changes I made before to NewS1 were just masking
the cache issue, I think, so I'll be taking that out.
I've also found some more instances (both in the back end and in the
translator) where checking for atoms doesn't work correctly in gcc4.1
without extra casts to unsigned long's and back to signed longs
(i.e., stuff like "if(top = HIGH_BITS >=0)". ecu kept crashing on me,
until I figured that one out.
It might be worth testing under windows whether it's still faster. I
wouldn't worry too much about the compatibility (MS does enough of
that), but the *nix stuff has apparently changed enough that it
doesn't really work anymore. As far as FreeBSD, when 7 is released,
it's supposed to have posix_memalign, so we won't have to fool with
worrying about alignment issues.
Matt
