Freezing strings?
Brent "Dax" Royal-Gordon
Parrot's configuration, so I'm trying to implement a library equivalent
to Parrot::Config. My current thoughts on implementation involve three
elements:
1. A Configure step that writes and executes a Parrot program. Said
program builds up a PerlHash of options and freezes it to disk.
2. Said frozen hash, stored in (e.g.) F<library/config.fpmc>.
3. A small chunk of code in (e.g.) F<library/config.imc> which reads
the frozen hash from disk and re-creates it.
This would guarantee that you're seeing the configuration info for the
current system, even if you moved a bytecode file with config.imc
compiled into it.
Unfortunately, I'm being stopped before I can even start. The following
code prints "foo=" on my Debian server:
new P0, .PerlString
set P0, "foo"
freeze S0, P0
thaw P1, S0
print P0
print "="
print P1
print "\n"
end
If I freeze a hash, the keys are preserved, but string values are lost.
Integer values are kept; float values all come out as 0.0 (plus or
minus about eight zeros).
F<t/pmc/freeze.t> doesn't test freezing and thawing strings or floats.
Is this because the functionality hasn't been implemented yet? A
cursory examination of F<src/pmc_freeze.c> suggests that it should be
working, but I may well be missing something.
If it's just some busywork, such as copying some code into PerlString
and tweaking it, I can probably do it, but I've been out of the loop for
a while, so anything particularly involved is likely beyond me.
--
Brent "Dax" Royal-Gordon <br...@brentdax.com>
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Leopold Toetsch
> F<t/pmc/freeze.t> doesn't test freezing and thawing strings or floats.
> Is this because the functionality hasn't been implemented yet?
Exactly. Sould be simple though. Please have a look at
classes/perlint.pmc (or such) that implement the freeze/thaw vtables.
> If it's just some busywork, such as copying some code into PerlString
> and tweaking it, I can probably do it, but I've been out of the loop for
> a while, so anything particularly involved is likely beyond me.
The interfaces are all there. It *should* just be:
- cut'n paste code from perlint
- s/_integer/_string/ for (push, shift) and s/int_val/str_val/
For debugging you could set FREEZE_ASCII in pmc_freeze.c albeit its not
saving the whole information.
leo
Brent "Dax" Royal-Gordon
>>If it's just some busywork, such as copying some code into PerlString
>>and tweaking it, I can probably do it, but I've been out of the loop for
>>a while, so anything particularly involved is likely beyond me.
>
> The interfaces are all there. It *should* just be:
> - cut'n paste code from perlint
> - s/_integer/_string/ for (push, shift) and s/int_val/str_val/
It was. I've committed it, along with a test for it. All tests pass on
Debian.
I also tried to add freeze and thaw to PerlNum (as long as I was
screwing around in that bit of the code), but the linker wasn't very
happy with that--complained about being unable to find
VTABLE_shift_number and VTABLE_push_number, so I undid that.
By the way, I never realized how patient you gcc guys were with the
computed-goto core--VC++ doesn't support it, so I didn't know that it
took so long to compile.
--
Brent "Dax" Royal-Gordon <br...@brentdax.com>
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
[I *will* learn to use Thunderbird correctly one of these days!]
Leopold Toetsch
>>
>> The interfaces are all there. It *should* just be:
>> - cut'n paste code from perlint
>> - s/_integer/_string/ for (push, shift) and s/int_val/str_val/
> It was. I've committed it, along with a test for it. All tests pass on
> Debian.
Whee. FTL check in :)
> I also tried to add freeze and thaw to PerlNum (as long as I was
> screwing around in that bit of the code), but the linker wasn't very
> happy with that--complained about being unable to find
> VTABLE_shift_number and VTABLE_push_number, so I undid that.
My fault. Mixed up shift_number vs shift_float. So the macros don't
match. You could just rename in pmc_freeze.h:
typedef struct _image_funcs
s/_number/_float/
or call the functions explicitely.
> By the way, I never realized how patient you gcc guys were with the
> computed-goto core--VC++ doesn't support it, so I didn't know that it
> took so long to compile.
Yep. Albeit newer gcc versions seem to be faster. BTW try an optimized
compile ...
leo
Brent "Dax" Royal-Gordon
> Brent "Dax" Royal-Gordon <br...@brentdax.com> wrote:
>>I also tried to add freeze and thaw to PerlNum (as long as I was
>>screwing around in that bit of the code), but the linker wasn't very
>>happy with that--complained about being unable to find
>>VTABLE_shift_number and VTABLE_push_number, so I undid that.
>
> My fault. Mixed up shift_number vs shift_float. So the macros don't
> match. You could just rename in pmc_freeze.h:
Renaming did it. freeze/thaw for PerlNum checked in, with test.
The first time I ran tests after compiling, I got a failure in
t/pmc/signals.t--it thought that no tests had run, and the harness
eventually reported 12/6 subtests of signals.t failed. Immediately
re-running make test came out fine; I added the new PerlNum test to
freeze.t and ran it a third time, which also passed. I guess it was a
fluke.
> Yep. Albeit newer gcc versions seem to be faster.
brent@server-navi/~/parrot% gcc -v
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
gcc version 2.95.4 20011002 (Debian prerelease)
So my compiler's almost as old as Parrot itself. Typical Debian. A
project for the weekend, perhaps...
Leopold Toetsch
> Renaming did it. freeze/thaw for PerlNum checked in, with test.
Fine, thanks.
> The first time I ran tests after compiling, I got a failure in
> t/pmc/signals.t--it thought that no tests had run, and the harness
> eventually reported 12/6 subtests of signals.t failed. Immediately
> re-running make test came out fine; I added the new PerlNum test to
> freeze.t and ran it a third time, which also passed. I guess it was a
> fluke.
It's mainly a problem with the test script (and likely timing of
that). The test is of course a big hack.
>> Yep. Albeit newer gcc versions seem to be faster.
> brent@server-navi/~/parrot% gcc -v
> Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
> gcc version 2.95.4 20011002 (Debian prerelease)
Pah. That's a really new one ;)
$ gcc -v
Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.2/specs
gcc version 2.95.2 19991024 (release)
But ony my laptop I have:
gcc-version 3.3.3 20040110 (prerelease) (Debian)
> So my compiler's almost as old as Parrot itself. Typical Debian. A
> project for the weekend, perhaps...
$ apt-get install gcc # w. appropriate sources.list?
leo