But not all of them compile to native. GNU CLISP compiles to byte
code
AFAIK.
From the CLISP manpage:
“Invoked with -c, the specified lisp files are compiled to a bytecode
that can be executed more efficiently.”Btw, I guess this is what - at the moment - Ruby does, too, isn’t it?
Currently it does not ever hit bytecode at all, it just interprets using
the stack as near as I can tell.
Charles Comstock
Mark Hubbart wrote:
Indeed, it does
I wasn’t thinking so much of translation to C, but
that would probably be much easier, and would be much better than not
having anything. And, it could pave the way for modifying a C compiler
to support the subset. (I hope I’m not being completely naiveIf there was a compiler, then it would be perfect for projects like
Rubyx and ROS. It would make it so that more people would be able to
participate, since they could leverage their Ruby skills towards the
project.
Mark,
I like the way you’re thinking. I believe the principal reason a Ruby
compiler (or C translator) doesn’t exist is simply that no one has
written one.
That being the case, go for it.
Of course, there are a few VM approaches out there (mostly experimental,
I think). There is also an rb2c which may still be in the RAA. (I
believe it was written for Ruby 1.4.x).
Of course, some aspects of such a project would be easier than others.
Cheers,
Hal
“Mark Hubbart” discord@mac.com schrieb im Newsbeitrag
news:BBFC9134-6A21-11D8-8CCB-000502FDD5CC@mac.com…
On Feb 28, 2004, at 3:46 AM, Tobias Nurmiranta wrote:
On Sat, 28 Feb 2004, Mark Hubbart wrote:
From my (very limited) experience with it, it doesn’t seem that lisp
has an eval statement, so much as lisp is an eval statementLisp has always had an eval statement, ever since 1960 when the first
paper on Lisp[1] was published.actually, I was meaning that as a joke. I haven’t ever gotten beyond
the very basics with lisp. To me, the “code is data is code” thing
makes me feel as if every statement is eval’ed… (“Which part’s the
code, and which part’s the data?” “Run it and figure it out.”) Please
excuse a novice
And because Lispers felt not confortable with the simple distinction of
code, data and eval they added macros.
robert
Disclaimer: This post is way off topic.
I am looking into a wireless setup and I have an L shape.
------------
Where each point is approx. 175 ft. from eachother in a straight line. I
will have a computer at each point on the L. I would like this to be all
wireless. I’ve been looking into Wireless AccessPoints, Routers and Bridges.
Any suggestions what should go where? Perhaps…
(access point)
>
>
>
>
>
>
------------
(router) (access point)
or do I need?
(router )
>
>
>
>
>
>
------------
(router) (router)
Any input is greatly appreciated. Thanks,
Zach
Hal Fulton wrote:
Mark Hubbart wrote:
Indeed, it does
that would probably be much easier, and would be much better
than not
having anything. And, it could pave the way for modifying a C compiler
to support the subset. (I hope I’m not being completely naiveIf there was a compiler, then it would be perfect for projects like
Rubyx and ROS. It would make it so that more people would be able to
participate, since they could leverage their Ruby skills towards the
project.Mark,
I like the way you’re thinking. I believe the principal reason a Ruby
compiler (or C translator) doesn’t exist is simply that no one has
written one.That being the case, go for it.
Of course, there are a few VM approaches out there (mostly experimental,
I think). There is also an rb2c which may still be in the RAA. (I
believe it was written for Ruby 1.4.x).
Or, how about instead of doing a compiler to emit machine code for some
particular architecture, instead do it to emit byte codes for the Parrot VM?
In other words, join the Cardinal project and help it to forge ahead!
Curt
Hal Fulton wrote:
I like the way you're thinking. I believe the principal reason a Ruby
compiler (or C translator) doesn't exist is simply that no one has
written one.
There are a few severe roadblocks to implementing this, the biggest one
being eval(). To support eval(), an executable needs access to the entire
Ruby interpreter. This interpreter can be in the form of a dynamic
library, but then there isn't much difference between installing Ruby and
installing the interpreter library. Or, the interpreter can be bundled
with the executable, which adds at least 5MB to the size of each executable
and still doesn't address the various library dependancies that can't be
discovered because of code like:
class Foo
def initialize
eval\( "require 'gtk'" \)
end
end
eval() is just one issue that confronts any attempt at creating an
application that converts Ruby to (C|Java|Native code|whatever), and I'm
sure there are others.
Which makes me think that a great thing to have would be a document that
identifies all of these cross-implementation difficulties. Maybe we could
come up with a "portable Ruby" specification -- a minimal description of
the set of Ruby features that can be implemented without having access to a
Ruby interpreter.
--
### SER
### Deutsch|Esperanto|Francaise|Linux|XML|Java|Ruby|Aikido
### http://www.germane-software.com/~ser jabber.com:ser ICQ:83578737
### GPG: http://www.germane-software.com/~ser/Security/ser_public.gpg
..
You just need a router/access point at the corner, and pc’s at the ends with
wireless net cards. Thats pretty much what I do at home. My router is a linux
box running rubyx with ethernet, broadband adsl and wireless cards. Works a
treat
Andrew
On Friday 27 Feb 2004 9:32 pm, Zach Dennis wrote:
Where each point is approx. 175 ft. from eachother in a straight line. I
will have a computer at each point on the L. I would like this to be all
wireless. I’ve been looking into Wireless AccessPoints, Routers and
Bridges. Any suggestions what should go where? Perhaps…
Well… for me to work on either project, I will have to do a lot of
brushing up on various things I have a feeling I won’t actually get
around to doing anything for at least a couple months, regardless.
But when I do, I think Cardinal would be a good project for me to pore
over. They would both be parsing Ruby and translating it into,
basically, another language Perhaps the C translation could even
build off of work done on cardinal! Parse the tree, then emit either
cardinal bytecode, or C code. So I think helping with the cardinal
project would benefit both projects.
What are the chances of Cardinal having the ability to emit more than
one type of code structure for the tree it parses? Could it possibly
end up pluggable?
–Mark
On Feb 27, 2004, at 9:37 PM, Curt Hibbs wrote:
Or, how about instead of doing a compiler to emit machine code for some
particular architecture, instead do it to emit byte codes for the
Parrot VM?In other words, join the Cardinal project and help it to forge ahead!
Until now, the FreeRIDE debugger did not work under windows. We now have a
maintenance release of FreeRIDE for Windows with a working debugger! Many
thanks for Mark Watson for discovering the solution.
There have been no changes to FreeRIDE itself. FreeRIDE on Windows has
always used its own private copy of Ruby to run FreeRIDE. This private copy
of Ruby has been upgraded to Ruby 1.8.1 and FXRuby 1.0.28.
For details and downloads, go to:
http://freeride.rubyforge.org/
=== FreeRIDE Overview ===
FreeRIDE aims to be a full-featured, first-class IDE on a par with those
available for other languages, with all the best-of-breed features that you
would expect in a high-end IDE.
Some of FreeRIDE’s current features include:
Some planned features include:
Curt Hibbs wrote:
Hal Fulton wrote:
Mark Hubbart wrote:
Indeed, it does
that would probably be much easier, and would be much betterthan not
having anything. And, it could pave the way for modifying a C compiler
to support the subset. (I hope I’m not being completely naiveIf there was a compiler, then it would be perfect for projects like
Rubyx and ROS. It would make it so that more people would be able to
participate, since they could leverage their Ruby skills towards the
project.Mark,
…
Or, how about instead of doing a compiler to emit machine code for some
particular architecture, instead do it to emit byte codes for the Parrot VM?In other words, join the Cardinal project and help it to forge ahead!
Curt
You mean like, say, a Ruby to MIX converter?
Less humorously, is cardinal moving forwards? I so rarely hear
anything even about Parrot that I was rather doubting this.
A compiler could attempt to translate evals into other constructs. I think most are simple enought to do that.
Open classes and self-modifying code are another problem. Conceivable, a ruby class could be be redefined a 1000 times during a programs execution. Still, most cases are probably addressable by the compiler.
5 mb is a big hit- maybe a special minimal gap-interpreter could be included that handles some of the weirder not-easily compilable cases?
Nick
Sean Russell wrote:
Hal Fulton wrote:
I like the way you're thinking. I believe the principal reason a Ruby
compiler (or C translator) doesn't exist is simply that no one has
written one.
There are a few severe roadblocks to implementing this, the biggest one
being eval(). To support eval(), an executable needs access to the entire
Ruby interpreter. This interpreter can be in the form of a dynamic
library, but then there isn't much difference between installing Ruby and
installing the interpreter library. Or, the interpreter can be bundled
with the executable, which adds at least 5MB to the size of each executable
and still doesn't address the various library dependancies that can't be
discovered because of code like:class Foo
def initialize
eval( "require 'gtk'" )
end
endeval() is just one issue that confronts any attempt at creating an
application that converts Ruby to (C|Java|Native code|whatever), and I'm
sure there are others.Which makes me think that a great thing to have would be a document that
identifies all of these cross-implementation difficulties. Maybe we could
come up with a "portable Ruby" specification -- a minimal description of
the set of Ruby features that can be implemented without having access to a
Ruby interpreter.
Mark Hubbart wrote:
What are the chances of Cardinal having the ability to emit more than
one type of code structure for the tree it parses? Could it possibly
end up pluggable?
It is my intention to do exactly this.
The plan is to write a class that outputs the correct code structure and
to pass an instance of that class into the compiler.
This is necessary since at somepoint the intermediate compiler will be
enhanced so that it can accept an abstract syntax tree and generate the
parrot byte code from that. So at that point it will be very useful to
be able to switch from outputting intermediate compiler code to just
serialising the AST.
–
Mark Sparshatt
In article AE7D2272-69BE-11D8-8CCB-000502FDD5CC@mac.com,
Or, how about instead of doing a compiler to emit machine code for some
particular architecture, instead do it to emit byte codes for the
Parrot VM?In other words, join the Cardinal project and help it to forge ahead!
Well… for me to work on either project, I will have to do a lot of
brushing up on various things
around to doing anything for at least a couple months, regardless.But when I do, I think Cardinal would be a good project for me to pore
over. They would both be parsing Ruby and translating it into,
basically, another language
build off of work done on cardinal! Parse the tree, then emit either
cardinal bytecode, or C code. So I think helping with the cardinal
project would benefit both projects.
There are several projects that could benefit. I actually think that what
we need is some directed effort put into a Ruby parser (frontend) of some
sort and then other (backend) projects like Cardinal could be plugged in.
It should be a whole other project (some already exist, like Ripper, Ruth,
Rockit, etc.) that is architected in such a way that it’s easy to plug in
different backends like:
Cardinal (emits Parrot bytecode)
Ruby2C (emits C code)
Ruby2Java(emits Java)
Ruby2Rite(emits Rite bytecode)
…etc.
What are the chances of Cardinal having the ability to emit more than
one type of code structure for the tree it parses? Could it possibly
end up pluggable?
Why not, there’s really not code or architecture to Cardinal yet.
However, I’m proposing that Cardinal just be a ‘backend’ project
(meaning that given some sort of AST it emits Parrot bytecode) and
that another frontend project be created to actually Parse Ruby. This
frontend project should be architected in such a way that it’s easy to
plug in different backends.
It could be that this frontend project already exists (I would tend to
thing so) in the form of Ripper or Ruth or Rockit. We just need to get a
consensus as to which of those projects to direct resources toward.
Phil
Hello Curt,
Sunday, February 29, 2004, 9:06:31 AM, you wrote:
Until now, the FreeRIDE debugger did not work under windows. We now have a
maintenance release of FreeRIDE for Windows with a working debugger! Many
thanks for Mark Watson for discovering the solution.
It does still not work. The maximum was 3 single step commands before
it crashed.
--------------------------------------------------------------
C:\Program Files\FreeRIDE>freeruby-win\bin\ruby.exe -I. -Iso -Iredist freeride.rb
Z:\work\arachno\test\python>
C:/Program Files/FreeRIDE/examples/HelloWorld/hello.rb on druby://scriptol-4sagyg:1708 attached.
C:/Program Files/FreeRIDE/redist/drb/drb.rb:497:in `proc': return jump can't across threads (ThreadE
rror)
from C:/Program Files/FreeRIDE/redist/drb/drb.rb:451:in `loop'
from C:/Program Files/FreeRIDE/redist/drb/drb.rb:500:in `proc'
from C:/Program Files/FreeRIDE/redist/drb/drb.rb:450:in `start'
from C:/Program Files/FreeRIDE/redist/drb/drb.rb:450:in `proc'
from C:/Program Files/FreeRIDE/redist/drb/drb.rb:419:in `run'
from C:/Program Files/FreeRIDE/redist/drb/drb.rb:416:in `start'
from C:/Program Files/FreeRIDE/redist/drb/drb.rb:416:in `run'
from C:/Program Files/FreeRIDE/redist/drb/drb.rb:377:in `initialize'
... 27 levels...
from C:/Program Files/FreeRIDE/freebase/lib/freebase/core.rb:35:in `new'
from C:/Program Files/FreeRIDE/freebase/lib/freebase/core.rb:35:in `startup'
from freeride.rb:80:in `startup'
from freeride.rb:92
--
Best regards,
Lothar mailto:mailinglists@scriptolutions.com
Charles Hixson wrote:
You mean like, say, a Ruby to MIX converter?
I think a ruby to Z machine converter would be more useful 
Less humorously, is cardinal moving forwards? I so rarely hear
anything even about Parrot that I was rather doubting this.
version 0.0.1 of cardinal has just been released. So it’s still very
early days there.
version 0.1.0 of parrot has also been released, which contains support
for objects. There are still some features missing but most of what’s
needed for object support is there.
–
Mark Sparshatt
Curt Hibbs wrote:
Until now, the FreeRIDE debugger did not work under windows. We now have a
maintenance release of FreeRIDE for Windows with a working debugger! Many
thanks for Mark Watson for discovering the solution.There have been no changes to FreeRIDE itself. FreeRIDE on Windows has
always used its own private copy of Ruby to run FreeRIDE. This private copy
of Ruby has been upgraded to Ruby 1.8.1 and FXRuby 1.0.28.
While I’m glad to hear that this is now working (for at least some
people), I’m a little curious about the solution that Mark Watson
discovered
I haven’t made any changes to FXRuby to try to accomodate the problem,
whatever it was (is). Is the fix then due to upgrading to Ruby 1.8.1?
“Curt Hibbs” wrote:
Until now, the FreeRIDE debugger did not work under windows. We now have a
maintenance release of FreeRIDE for Windows with a working debugger! Many
thanks for Mark Watson for discovering the solution.
The debugger appears to crash when executing an eval, here’s wot I tried debugging:
class A
def initialize
eval(“@a = Hash.new”)
end
end
b = A.new
I’m running on Windows XP- SP1
Here’s the trace left in the console:
C:\Program Files\FreeRIDE>freeruby-win\bin\ruby.exe -I. -Iso -Iredist freeride.rb
c:/ruby/frdebugtest.rb on druby://agamemnon:1339 attached.
C:/Program Files/FreeRIDE/redist/drb/drb.rb:497:in proc': return jump can't across threads (ThreadError) from C:/Program Files/FreeRIDE/redist/drb/drb.rb:451:in loop’
from C:/Program Files/FreeRIDE/redist/drb/drb.rb:500:in proc' from C:/Program Files/FreeRIDE/redist/drb/drb.rb:450:in start’
from C:/Program Files/FreeRIDE/redist/drb/drb.rb:450:in proc' from C:/Program Files/FreeRIDE/redist/drb/drb.rb:419:in run’
from C:/Program Files/FreeRIDE/redist/drb/drb.rb:416:in start' from C:/Program Files/FreeRIDE/redist/drb/drb.rb:416:in run’
from C:/Program Files/FreeRIDE/redist/drb/drb.rb:377:in initialize' ... 23 levels... from C:/Program Files/FreeRIDE/freebase/lib/freebase/core.rb:35:in new’
from C:/Program Files/FreeRIDE/freebase/lib/freebase/core.rb:35:in startup' from freeride.rb:80:in startup’
from freeride.rb:92
–
J. Lambert
I have just downloaded FreeRIDE, and it could not debug. I tried a console
app, and a GTK app.
Also, why FreeRIDE does NOT support breakpoints?
Is there a hook in the interpreter for the breakpoints?
I tried using -rdebug before, but this makes the program too slow. -rdebug
callbacks are definitelly not meant for debugging.
–
-Laza
http://lazax.com/blog
On Sun, 29 Feb 2004 17:06:31 +0900, Curt Hibbs curt@hibbs.com wrote:
Until now, the FreeRIDE debugger did not work under windows. We now have
a
maintenance release of FreeRIDE for Windows with a working debugger! Many
thanks for Mark Watson for discovering the solution.There have been no changes to FreeRIDE itself. FreeRIDE on Windows has
always used its own private copy of Ruby to run FreeRIDE. This private
copy
of Ruby has been upgraded to Ruby 1.8.1 and FXRuby 1.0.28.For details and downloads, go to:
It is difficult already to implement reification in compiled code, and
it is even more difficult to implement intercession (having just gone
through a myriad of papers covering all sorts of aspects related to
this I've gained an idea on just what a monumental job that is).
However, if (and that's a BIG IF) one's code can work without needing
such features then it makes it much more easier to be compiled. Now
the question is: how much are we willing to sacrifice to be able to
compile the code?
On Fri, 11 Jun 2004 13:00:57 +0900, Nicholas Van Weerdenburg <nick@activehitconsulting.com> wrote:
A compiler could attempt to translate evals into other constructs. I
think most are simple enought to do that.Open classes and self-modifying code are another problem. Conceivable, a
ruby class could be be redefined a 1000 times during a programs
execution. Still, most cases are probably addressable by the compiler.5 mb is a big hit- maybe a special minimal gap-interpreter could be
included that handles some of the weirder not-easily compilable cases?Nick
Sean Russell wrote:
>Hal Fulton wrote:
>
>
>
>>I like the way you're thinking. I believe the principal reason a Ruby
>>compiler (or C translator) doesn't exist is simply that no one has
>>written one.
>>
>>
>
>There are a few severe roadblocks to implementing this, the biggest one
>being eval(). To support eval(), an executable needs access to the entire
>Ruby interpreter. This interpreter can be in the form of a dynamic
>library, but then there isn't much difference between installing Ruby and
>installing the interpreter library. Or, the interpreter can be bundled
>with the executable, which adds at least 5MB to the size of each executable
>and still doesn't address the various library dependancies that can't be
>discovered because of code like:
>
> class Foo
> def initialize
> eval( "require 'gtk'" )
> end
> end
>
>eval() is just one issue that confronts any attempt at creating an
>application that converts Ruby to (C|Java|Native code|whatever), and I'm
>sure there are others.
>
>Which makes me think that a great thing to have would be a document that
>identifies all of these cross-implementation difficulties. Maybe we could
>come up with a "portable Ruby" specification -- a minimal description of
>the set of Ruby features that can be implemented without having access to a
>Ruby interpreter.
>
>
>
"Nicholas Van Weerdenburg" <nick@activehitconsulting.com> schrieb im
Newsbeitrag news:40C92E6E.9040708@activehitconsulting.com...
A compiler could attempt to translate evals into other constructs. I
think most are simple enought to do that.
It's not the complexity of the statement but the dynamic. How should a
compiler compile something that isn't known until runtime?
Open classes and self-modifying code are another problem. Conceivable, a
ruby class could be be redefined a 1000 times during a programs
execution. Still, most cases are probably addressable by the compiler.
That might work.
Regards
robert