Re: More object stuff
Dan Sugalski wrote: At 1:02 PM + 12/27/03, Harry Jackson wrote: Being fairly new to parrot and probably naive I can see a few different ways of doing this. A C wrapper ie: parrot/classes/parrotdbi.pmc etc A C wrapper ie: parrot/dynclasses/parrotdbi.pmc etc A loadable pasm function library that uses the current libpq/(other libs) and available available ops. I'd go with option 3, the loadable pasm library that uses the current libpq. I think that, right now, there's no need for anything else. That may turn out to be incorrect, but if so we can try Plan B. (Which involves either extending Parrot or getting the C extension stuff working) OK. I will start on it now. I will probably have lots of questions while doing this. Tim's right -- dodge the DBD/DBI names for right now. We're going to have enough of a headache with those later, what with there being both Ruby and Perl versions that use it. (Possibly Python too, I'm not sure) I was only using them as examples. I will leave them pretty generic ie for the time being. > getting back a full row as an array, getting back a full row as a hash, and stuff like that. Nothing fancy, and nothing that high-level, but enough to work the basics without quite as manual work as the current libpg requires. This'll probably be the basis for the DB driver interface for Parrot's DBI library, so this is your chance to make a mark. :) Cheers for the opportunity. Always happy to pass on work to other people. :) As soon as I have a something of worth I will post the details. H
Re: a Parrot plugin for Mozilla
On Tue, 30 Dec 2003 08:48, Stephane Peiry wrote; > For some reason.. always wanted to be able to write (and get) perl > applets on web browsers, so attached here is my go at a parrot plugin > for Mozilla :) Wow, fantastic! Now, wouldn't it be nice if someone wrote an ECMAScript front-end to Parrot, so that Parrot might stand a chance of usurping Spidermonkey in Mozzy? Just a thought... -- Sam Vilain, [EMAIL PROTECTED]
Problem during "make test"
During
[EMAIL PROTECTED] parrot]$ make test
echo imcc/imcc.y -d -o imcc/imcparser.c
imcc/imcc.y -d -o imcc/imcparser.c
perl -e 'open(A,qq{>>$_}) or die foreach @ARGV' imcc/imcc.y.flag
imcc/imcparser.c imcc/imcparser.h
perl t/harness --gc-debug --running-make-test -b t/op/*.t t/pmc/*.t
t/native_pbc/*.t
t/op/00ff-dos...
This is as far as it gets. I am assuming since no one else has noticed
this that it is a problem with my set up but I am at a bit of a loss as
to what has happened to cause it.
It gets even stranger. If I do a make clean and make test again it does
not necessarily stop in the same place each time ie.
perl t/harness --gc-debug --running-make-test -b t/op/*.t t/pmc/*.t
t/native_pbc/*.t
t/op/00ff-dos...ok
t/op/00ff-unix..
sometime it gets as far as the aritmetic tests. Has anyone seen this
before. My myconfig is at the bottom of the page.
On a side note I noticed some warnings about a predeclared variable in
/parrot/ops/core.ops line 1059. Patch attached.
Summary of my parrot 0.0.13 configuration:
configdate='Mon Dec 29 21:21:06 2003'
Platform:
osname=linux, archname=i386-linux
jitcapable=1, jitarchname=i386-linux,
jitosname=LINUX, jitcpuarch=i386
execcapable=1
perl=perl
Compiler:
cc='gcc', ccflags=' -I/usr/local/include',
Linker and Libraries:
ld='gcc', ldflags=' -L/usr/local/lib',
cc_ldflags='',
libs='-lnsl -ldl -lm -lcrypt -lutil -lpthread'
Dynamic Linking:
so='.so', ld_shared='-shared -L/usr/local/lib',
ld_shared_flags=''
Types:
iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4,
ptrsize=4, ptr_alignment=4 byteorder=1234,
nv=double, numvalsize=8, doublesize=8
--- core.opsMon Dec 29 22:06:55 2003
+++ core.ops.newMon Dec 29 22:07:59 2003
@@ -1056,7 +1056,7 @@
VTABLE_type(interpreter, overflow) != enum_class_Null &&
((elems_in_array = VTABLE_get_integer(interpreter, overflow)) != 0)) {
INTVAL cur_elem;
- INTVAL start = 0;
+ start = 0;
if ($2 > 11) {
start = $2 - 11;
}
Re: I could not resist
> "HJ" == Harry Jackson <[EMAIL PROTECTED]> writes: HJ> I was searching on google for HJ> core.html parrot HJ> http://www.gurney.co.uk/parrots/dandan.html and if dan keeps leading parrot he will soon pluck out his own hairs (there is a name for this human neurotic disease). :) uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
I could not resist
I was searching on google for core.html parrot and the first link took me to http://www.gurney.co.uk/parrots/dandan.html Do we have a facilty for number 5. H
Re: Garbage Collection Tasks
At 11:28 AM -0800 12/29/03, Jeff Clites wrote: On Dec 29, 2003, at 8:13 AM, Dan Sugalski wrote: 2) We need a more traditional, non-moving GC as an alternative to the copying collector. A modified mark & sweep'd be fine, but as it'll be living behind the API it doesn't much matter. This is really only for the chunks of memory backing strings and such, right? We're already using mark-and-sweep for PMCs and strings and such (that is, their headers), right? Right, this is for the memory pools backing string bodies and other variable-length things. As I see it, it's really the allocation that is more complicated with a mark-and-sweep collector (since you have to search for a correct-sized free chunk, efficiently)--the collection itself is the easy part. Actually, it seems like this is just the GC_IS_MALLOC case--that already gives us non-moving GC, and lets malloc (the system version or the Lea version) deal with managing the bookkeeping. Allocation's more complex, but so is deallocation. Properly maintaining a free list with adjacent piece coalescing can be non-trivial, and there's the added complication of COW so multiple string headers may be pointing to the same chunk of memory, so freeing up one's not a sufficient reason to return the memory to the free pool. #2 is a bit more interesting and, if we do it right, means that we'll end up with a pluggable garbage collection system and may (possibly) be able to have type 3 threads share object arenas and memory pools, which'd be rather nice. Even if not, it leaves a good window for experimentation in allocation and collection, which isn't bad either. This, combined with the mention of needing to drive this off of a vtable, means being able to determine the GC algorithm at runtime instead of compile-time (i.e., that was part of your point). I'm all for that--it will mean less #if's in the code, and it will make the code a bit clearer. Yep. Care to take a shot at it? -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
a Parrot plugin for Mozilla
Hi All,
For some reason.. always wanted to be able to write (and get) perl
applets on web browsers, so attached here is my go at a parrot plugin
for Mozilla :)
The files attached are:
The plugin.tar is the one containing it mainly with some instructions
on how to build it (and test it).
Since I need to pass onto parrot the pointer to the boxing window
(container) for the plugin in Mozilla, I have done this by pointing an
UnManagedStruct to it, hence the "set_pointer" patch attached for the
UnManagedStruct PMC:
As well, Gtk2 was used to test the plugin, so attached is a file with
required gtk.declarations plus a call_list.txt.patch if the signatures
for it are not built "on the fly".
The examples merely display widgets in the Mozilla window as callbacks
to Parrot still need some work (but thats the Parrot side, so applets
will get better as soon as we have these ;)
Have fun :)
StÃphane
PS.: I noticed that somehow recently where added to Parrot, and
somehow this breaks the plugin when hitting reload on Mozilla. Comenting
out Parrot_init_events(interpreter) in interpreter.c resolves the
problem: is the event queue properly cleaned up on Parrot_destroy?
plugin.tar.gz
Description: GNU Zip compressed data
Index: unmanagedstruct.pmc
===
RCS file: /cvs/public/parrot/classes/unmanagedstruct.pmc,v
retrieving revision 1.22
diff -u -r1.22 unmanagedstruct.pmc
--- unmanagedstruct.pmc 4 Nov 2003 18:35:05 - 1.22
+++ unmanagedstruct.pmc 29 Dec 2003 18:34:08 -
@@ -246,6 +246,10 @@
return PMC_data(SELF);
}
+void set_pointer (void* value) {
+PMC_data(SELF) = value;
+}
+
void set_integer_native(INTVAL value) {
*(INTVAL *)PMC_data(SELF) = value;
}
[package]
Gtk
[lib]
libgtk-x11-2.0
[defs]
v gtk_init ii
v gtk_main v
p gtk_calendar_new v
# -- Gtk Widget
#p gtk_widget_new it# -- Check this (ellipsis)
p gtk_widget_ref p
v gtk_widget_unrefp
v gtk_widget_destroy p
#v gtk_widget_destroyedpp# -- Check this.
#v gtk_widget_set pt# -- Check this (ellipsis)
v gtk_widget_unparent p
v gtk_widget_show p
v gtk_widget_show_now p
v gtk_widget_hide p
v gtk_widget_show_all p
v gtk_widget_hide_all p
v gtk_widget_map p
v gtk_widget_unmapp
v gtk_widget_realize p
v gtk_widget_unrealizep
v gtk_widget_queue_draw p
v gtk_widget_queue_resize p
v gtk_widget_draw pp
v gtk_widget_size_request pp
v gtk_widget_get_child_requisitionpp
v gtk_widget_size_allocatepp
v gtk_widget_add_accelerator ptpiii
i gtk_widget_remove_accelerator ppii
v gtk_widget_set_accel_path ptp
p gtk_widget_list_accel_closures p
i gtk_widget_eventpp
i gtk_widget_activate p
v gtk_widget_reparent pp
i gtk_widget_intersectppp
i gtk_widget_is_focus p
v gtk_widget_grab_focus p
v gtk_widget_grab_default p
v gtk_widget_set_name pt
t gtk_widget_get_name p
v gtk_widget_set_statepi
v gtk_widget_set_sensitivepi
v gtk_widget_set_parent pp
v gtk_widget_set_parent_windowpp
p gtk_widget_get_parent_windowp
v gtk_widget_set_upositionpii
v gtk_widget_set_usizepii
v gtk_widget_set_events pi
v gtk_widget_add_events pi
v gtk_widget_set_extension_events pi
i gtk_widget_get_extension_events p
p gtk_widget_get_toplevel p
p gtk_widget_get_ancestor pi
p gtk_widget_get_colormap p
v gtk_widget_set_colormap pp
p gtk_widget_get_visual p
i gtk_widget_get_events p
v gtk_widget_get_pointer pii
i gtk_widget_is_ancestor pp
i gtk_widget_translate_coordinatespp
i gtk_widget_hide_on_delete p
v gtk_widget_set_stylepp
v
Re: Garbage Collection Tasks
On Dec 29, 2003, at 8:13 AM, Dan Sugalski wrote: 2) We need a more traditional, non-moving GC as an alternative to the copying collector. A modified mark & sweep'd be fine, but as it'll be living behind the API it doesn't much matter. This is really only for the chunks of memory backing strings and such, right? We're already using mark-and-sweep for PMCs and strings and such (that is, their headers), right? As I see it, it's really the allocation that is more complicated with a mark-and-sweep collector (since you have to search for a correct-sized free chunk, efficiently)--the collection itself is the easy part. Actually, it seems like this is just the GC_IS_MALLOC case--that already gives us non-moving GC, and lets malloc (the system version or the Lea version) deal with managing the bookkeeping. #2 is a bit more interesting and, if we do it right, means that we'll end up with a pluggable garbage collection system and may (possibly) be able to have type 3 threads share object arenas and memory pools, which'd be rather nice. Even if not, it leaves a good window for experimentation in allocation and collection, which isn't bad either. This, combined with the mention of needing to drive this off of a vtable, means being able to determine the GC algorithm at runtime instead of compile-time (i.e., that was part of your point). I'm all for that--it will mean less #if's in the code, and it will make the code a bit clearer. JEff
Re: More object stuff
At 1:02 PM + 12/27/03, Harry Jackson wrote: Dan Sugalski wrote: Dunno if I replied, but... Next step is a higher level wrapper, if you're up for fiddling with Postgres itself. Stuff like a single call > to connect (right now you have to make the connect call and poll over and over again), I did some benchmarks using your original library a few weeks ago and I did find the polling business a bit odd. I replied a while back asking asking if anyone had any pointers or examples on where to start this no matter how simple but I think "Warnock's Dilema #2" may have kicked in. D'oh! I thought I'd replied, but I guess not. Being fairly new to parrot and probably naive I can see a few different ways of doing this. A C wrapper ie: parrot/classes/parrotdbi.pmc etc A C wrapper ie: parrot/dynclasses/parrotdbi.pmc etc A loadable pasm function library that uses the current libpq/(other libs) and available available ops. I'd go with option 3, the loadable pasm library that uses the current libpq. I think that, right now, there's no need for anything else. That may turn out to be incorrect, but if so we can try Plan B. (Which involves either extending Parrot or getting the C extension stuff working) Tim's right -- dodge the DBD/DBI names for right now. We're going to have enough of a headache with those later, what with there being both Ruby and Perl versions that use it. (Possibly Python too, I'm not sure) > getting back a full row as an array, getting back a full row as a hash, and stuff like that. Nothing fancy, and nothing that high-level, but enough to work the basics without quite as manual work as the current libpg requires. This'll probably be the basis for the DB driver interface for Parrot's DBI library, so this is your chance to make a mark. :) Cheers for the opportunity. Always happy to pass on work to other people. :) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Garbage Collection Tasks
Well, two tasks actually. What with threads coming in, some of the limitations of a copying collector are becoming very apparent. While it's really nice, and just feels really cool, in the single-threaded case, neither nice nor cool justifies potentially massive headaches and synchronization issues when sharing data between interpreters. So, time for some work. The task is twofold: 1) The garbage collection and memory allocation APIs needs to be formalized and abstracted a bit. (We're likely most of the way there, but it's been a while since I've looked and, honestly, the GC/DOD system's seen some pretty major upheavals since then) It also needs to live in a vtable of sorts that can hang off the interpreter, so we can swap it out as need be. 2) We need a more traditional, non-moving GC as an alternative to the copying collector. A modified mark & sweep'd be fine, but as it'll be living behind the API it doesn't much matter. #1 is a bit of code digging and gruntwork combined with a bit of thought (if the API needs formalizing) and can be done even if you've no clue what's going on in the GC or DOD. #2 is a bit more interesting and, if we do it right, means that we'll end up with a pluggable garbage collection system and may (possibly) be able to have type 3 threads share object arenas and memory pools, which'd be rather nice. Even if not, it leaves a good window for experimentation in allocation and collection, which isn't bad either. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: PMC registry
Sam Vilain <[EMAIL PROTECTED]> writes: > Presumably this all means that Parrot will be able to due ruby-esque > iteration over all objects (if I may use the term PMC to refer to an > object ;-)) that have been created? ITYM "Smalltalkesque". HTH, HAND. > -- > Sam Vilain, [EMAIL PROTECTED] > > The meek shall inherit the earth, but not its mineral rights. > J PAUL GETTY
