Klaas-Jan Stol wrote:
Hi,
I've spent some time on refactoring imcc's parser and lexer a bit (only
minor) and I guess the time has come for some design decisions, if possible.
Currently, IMCC handles both PIR and PASM. smash++ suggested that PDDs
should be finished for both PASM and PIR.
Once PA
Just a following followup - I looked ath changes in rev 21619 and noticed
that the troublesome warning flags are still in the "cage" settings for
the default. Should they be moved to a v3.4 section also for the cage
cleaners?
a
Andy Bach
Systems Mangler
Internet: [EMAIL PROTECTED]
VOICE: (608
Paul wrote:
> This should be corrected as of revision 21619. Could you confirm that
this works for you?
Yep, make smoke worked last night. Thanks.
> Have you been using the parrotbug script? If so, it is known that it
doesn't work properly.
Yeah, I tried that twice and then went to the email.
On Sep 28, 12:45 am, [EMAIL PROTECTED] (Bernhard
Schmalhofer) wrote:
> Klaas-Jan Stol schrieb:> hi,
>
> > attached a patch that adds ".label" as a directive to declare labels
> > in a macro.
> Applied in r21624.
thanks!
>
> > The big overall cunning plan is to remove ".local" for this purpose
> >
Klaas-Jan Stol schrieb:
hi,
attached a patch that adds ".label" as a directive to declare labels
in a macro.
Applied in r21624.
The big overall cunning plan is to remove ".local" for this purpose
(defining labels), and to use ".local" ONLY for declaring variables.
Then, once all ".local"
Hi,
I've spent some time on refactoring imcc's parser and lexer a bit (only
minor) and I guess the time has come for some design decisions, if possible.
Currently, IMCC handles both PIR and PASM. smash++ suggested that PDDs
should be finished for both PASM and PIR.
Once PASM has been well-defined
hi,
attached a patch that adds ".label" as a directive to declare labels in a
macro.
The big overall cunning plan is to remove ".local" for this purpose
(defining labels), and to use ".local" ONLY for declaring variables.
Then, once all ".local" (in macros) are replaced by ".label", we can start
It doesn't work completely with FreeBSD's make it seems. Building
'parrot' works just fine, dynpmc stuff fails with this.
g++ -o ./parrot src/main.o blib/lib/libparrot.a -lpthread -lm
-L/usr/local/lib -licuuc -licudata -lpthread -lm -lm -lcrypt -lutil
-pthread -lreadline -Wl,-E -L/usr/l
yes, there is a race condition, which we discussed briefly on IRC. i
stayed away from fcntl/flock for portability reasons, but i honestly
didn't spend too much time researching it.
that said, i'm all for avoiding race conditions, so i'd be curious to see
some platform tests with the fnctl pat
