wxWindows Support
David
would be a good combination. Is there any interest in supporting wxWindows in
Parrot?
Thanks.
-- David Cuny
*: For those not familiar with it, wxWindows (http://www.wxwindows.org) is an
open source, cross-platform native UI framework for Windows, Unix/GTK+,
Unix/Motif and X11, MacOS, MGL and OS/2. It also provides network
programming, streams, clipboard and drag and drop, multithreading, image
loading and saving in a variety of popular formats, database support, etc.
Sorry for sounding like an advertisement; I'm cutting and pasting off the
website.
And yes, there is a wxPerl (http://wxperl.sourceforge.net/).
Dan Sugalski
>There was a recent mention on the wxWindows* list that pairing it with Parrot
>would be a good combination. Is there any interest in supporting wxWindows in
>Parrot?
On the one hand, I don't particularly care to bless a windowing
toolkit, since they all have cross-platform issues (either
functionally or in appearance) but I have no problem at all if
someone wants to build a Parrot interface to one of the kits and
putting it in an extended library distribution.
>-- David Cuny
>
>*: For those not familiar with it, wxWindows (http://www.wxwindows.org) is an
>open source, cross-platform native UI framework for Windows, Unix/GTK+,
>Unix/Motif and X11, MacOS, MGL and OS/2. It also provides network
>programming, streams, clipboard and drag and drop, multithreading, image
>loading and saving in a variety of popular formats, database support, etc.
>
>Sorry for sounding like an advertisement; I'm cutting and pasting off the
>website.
>
>And yes, there is a wxPerl (http://wxperl.sourceforge.net/).
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Christian Renz
in some discussion about the future of wxWindows ;-).
I'm not looking for official endorsement of wxWindows as "the"
GUI toolkit for Parrot -- TIMTOWTDI -- but it sure would be sweet to
have, and definitely would not hurt Parrot-based application
development :).
When starting to think about this, I asked myself what library
interfacing with Parrot would look like. My first thought was to have
a Perl 6 interface for wxWindows, but then it ocurred to me that it
would be more clever to have all the interface classes in Parrot; this
way, _any_ language using Parrot could use the wxWindows classes. Is
this correct? Are there already tools to do the interfacing (á la
Swig) or does it need to be done by hand?
Greetings,
Christian
--
cr...@web42.com - http://www.web42.com/crenz/ - http://www.web42.com/
"One of the problems with Java is that they swept a bit too much of the
innate complexity of life under the carpet of the libraries. And so
now they've had to replace the carpets several times." -- Larry Wall
Christian Renz
>have, and definitely would not hurt Parrot-based application
Whoops. Just to clarify: It would be sweet to have an interface for
wxWindows in Parrot -- not the official endorsement.
And let me try to formulate a nice and clear question:
What is the easiest way to make a monster like wxWindows (in terms of
classes) available for Parrot?
(Or would it be easier to write a Parrot backend for gcc? ;-))
"A man can no more diminish God's glory by refusing to worship Him than
a lunatic can put out the sun by scribbling the word 'darkness' on
the walls of his cell." -- C.S. Lewis
Leopold Toetsch
> What is the easiest way to make a monster like wxWindows (in terms of
> classes) available for Parrot?
The easiest way isn't avaialble yet. That is custom dynamically loaded
PMCs (classes) representing some functionality. Alreay working is the
NCI (Native call interface) to call arbitrary C functions in some shared
libs (modulo some struct handling and such, but e.g ncurses.so is
running). Setting up required struct's from PASM isn't yet. As wxWindows
is object oriented it would for sure better plug in Parrot's OO scheme,
which is almost, hmm, well, ready ... (DAN) ...
> (Or would it be easier to write a Parrot backend for gcc? ;-))
Why the smilies ;-) Parrot is a fine processor well suited for an
optimizing compiler and with a reasonable architecture. Its not the
first time that I'm thinking of such a hack.
... though it would need some extensions at both sides.
Are some gcc people listening?
leo
Christian Renz
>PMCs (classes) representing some functionality.
Hmm... then I think I misunderstood something. I thought PMCs are
only used for language-specific data types (e.g. "PerlScalar",
"PythonString") that are part of the Parrot core and not so much for
user-defined types that I can hook up with Parrot myself. I also
thought that PMCs only support basic operations rather than being
full-fledged classes.
Sorry if I sound a bit ignorant of Parrot internals. That's because I
am :) although I try my best to follow Parrot development.
When Parrot's OO handling is ready, will it use PMC for external
classes (ie. classes in binary form rather than Parrot bytecode) or
something else?
>Why the smilies ;-)
Because my guess was that if such a beast is possible, it's gonna be a
lot of work. After all, Parrot seems to be much more intelligent than
the average CPU out there :).
Greetings,
Christian
Leopold Toetsch
>> The easiest way isn't avaialble yet. That is custom dynamically loaded
>> PMCs (classes) representing some functionality.
>
> Hmm... then I think I misunderstood something. I thought PMCs are
> only used for language-specific data types (e.g. "PerlScalar",
I thought of wxWindows data structures in PMCs. The word "funcionality"
was probably misleading.
> When Parrot's OO handling is ready, will it use PMC for external
> classes (ie. classes in binary form rather than Parrot bytecode) or
> something else?
I'm sure that sometimes these can be mixed.
[ gcc backend]
> Because my guess was that if such a beast is possible, it's gonna be a
> lot of work. After all, Parrot seems to be much more intelligent than
> the average CPU out there :).
That for sure is true. PMCs and string registers/functions are very
different to an average hardware CPU.
> Greetings,
> Christian
leo
Tupshin Harper
> Why the smilies ;-) Parrot is a fine processor well suited for an
> optimizing compiler and with a reasonable architecture. Its not the
> first time that I'm thinking of such a hack.
>
> ... though it would need some extensions at both sides.
> Are some gcc people listening?
>
>
> leo
I'm not a "GCC person", but I do have an interest in this working. I did
some exploratory work (mostly getting familiar with the GCC backend
mechanism and with PASM), and quickly ran into what appeared to be
fundamental roadblocks regarding gcc's predilection for generating
stack-oriented assembly. Do you have some insights into what the most
viable path for GCC--->pasm could be?
-Tupshin
Leopold Toetsch
>
> I'm not a "GCC person", but I do have an interest in this working. I did
> some exploratory work (mostly getting familiar with the GCC backend
> mechanism and with PASM), and quickly ran into what appeared to be
> fundamental roadblocks regarding gcc's predilection for generating
> stack-oriented assembly. Do you have some insights into what the most
> viable path for GCC--->pasm could be?
No :-) Most processors work stack-oriented. AFAIK does have the ia64 cpu
some deviations like register windows. But parrot - and the more with
CPS subroutines - is really different. And parrot has a different ABI too.
Translating IReg and Nreg operations wouldn't be too hard, but what
about strings (and functions) and objects. I think, that is impossible.
Targeting native C is not a primary goal, just some "nice to have". IIRC
do the mono people have a C parser too and there are some thoughts to
translate C/C# to parrot, so I can imagine, that there might be some
more in the future.
> -Tupshin
leo
Tupshin Harper
> Tupshin Harper wrote:
>
>>
>> I'm not a "GCC person", but I do have an interest in this working. I
>> did some exploratory work (mostly getting familiar with the GCC
>> backend mechanism and with PASM), and quickly ran into what appeared
>> to be fundamental roadblocks regarding gcc's predilection for
>> generating stack-oriented assembly. Do you have some insights into
>> what the most viable path for GCC--->pasm could be?
>
>
> No :-) Most processors work stack-oriented. AFAIK does have the ia64
> cpu some deviations like register windows. But parrot - and the more
> with CPS subroutines - is really different. And parrot has a different
> ABI too.
> Translating IReg and Nreg operations wouldn't be too hard, but what
> about strings (and functions) and objects. I think, that is impossible.
I'm confused...it sounds like you are talking about translating
pbc->regular CPU, and I'm thinking the opposite.
>
>
> Targeting native C is not a primary goal, just some "nice to have".
> IIRC do the mono people have a C parser too and there are some
> thoughts to translate C/C# to parrot, so I can imagine, that there
> might be some more in the future.
>
>> -Tupshin
>
>
> leo
>
Here's a wacky idea. What about emulating a more traditional
stack-oriented processor in parrot? (What...surely you jest). Seriously,
though, it might actually be a really thin emulation layer. You add some
PMC's to handle C-style stacks and any other CPU oddities that would be
expected of a back-end by a compiler. How complicated could it be?
Obviously performance would suffer, but it seems workable.
-Tupshin
Benjamin Goldberg
>
> Tupshin Harper wrote:
>
> >
> > I'm not a "GCC person", but I do have an interest in this working. I
> > did some exploratory work (mostly getting familiar with the GCC
> > backend mechanism and with PASM), and quickly ran into what appeared
> > to be fundamental roadblocks regarding gcc's predilection for
> > generating stack-oriented assembly. Do you have some insights into
> > what the most viable path for GCC--->pasm could be?
>
> No :-) Most processors work stack-oriented. AFAIK does have the ia64
> cpu some deviations like register windows. But parrot - and the more
> with CPS subroutines - is really different. And parrot has a different
> ABI too.
> Translating IReg and Nreg operations wouldn't be too hard, but what
> about strings (and functions) and objects. I think, that is
> impossible.
Since the discussion is (gcc-produced-)assembly to pasm, we're
fortunate... there aren't any "objects" to translate from asm to pasm :)
For strings, the real challenge is identifying when the assembler is
manipulating something which should be thought of as a string, or when
it is manipulating something which should be thought of as an array of
character-sized integers; then we use either Sreg operations, or Preg
operations (operating on some Array (sub-)type).
> Targeting native C is not a primary goal, just some "nice to have".
> IIRC do the mono people have a C parser too and there are some
> thoughts to translate C/C# to parrot, so I can imagine, that there
> might be some more in the future.
Translating from pasm to C would be very similar to our jit, except that
instead of outputing assembler, we would output C source code, most of
which could probably be generated from the data in our *.ops files.
--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "$@[$a%6
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}
Tupshin Harper
>Leopold Toetsch wrote:
>
>
>>Tupshin Harper wrote:
>>
>>
>>
>>>I'm not a "GCC person", but I do have an interest in this working. I
>>>did some exploratory work (mostly getting familiar with the GCC
>>>backend mechanism and with PASM), and quickly ran into what appeared
>>>to be fundamental roadblocks regarding gcc's predilection for
>>>generating stack-oriented assembly. Do you have some insights into
>>>what the most viable path for GCC--->pasm could be?
>>>
>>>
>>No :-) Most processors work stack-oriented. AFAIK does have the ia64
>>cpu some deviations like register windows. But parrot - and the more
>>with CPS subroutines - is really different. And parrot has a different
>>ABI too.
>>Translating IReg and Nreg operations wouldn't be too hard, but what
>>about strings (and functions) and objects. I think, that is
>>impossible.
>>
>>
>
>Since the discussion is (gcc-produced-)assembly to pasm, we're
>fortunate... there aren't any "objects" to translate from asm to pasm :)
>
>For strings, the real challenge is identifying when the assembler is
>manipulating something which should be thought of as a string, or when
>it is manipulating something which should be thought of as an array of
>character-sized integers; then we use either Sreg operations, or Preg
>operations (operating on some Array (sub-)type).
>
My point with my previous response to Leopold's mail was that you could
actually do CPU emulation at such a low parrot level that you wouldn't
even have to do that (e.g. identify strings vs. array of int's)
initially. You emulate at the register and opcode level. Performance
would suffer (quite a bit), but you could get it working pretty easily.
Then it's a matter of gradual optimization to recognize lower level
structures that can map to more complex higher level parrot equivalents.
-Tupshin