Nicholas Van Weerdenburg <nick@activehitconsulting.com> wrote in message news:<40C92E6E.9040708@activehitconsulting.com>...
A compiler could attempt to translate evals into other constructs. I
think most are simple enought to do that.
No. Simply grep through the 1.8.1 standard library and you see that
it is used a lot in non trivial situations.
That sounds great! Sounds like I have a lot of reading to do… 
Great name, btw.
–Mark the other
On Feb 28, 2004, at 12:36 AM, Mark wrote:
The plan is to write a class that outputs the correct code structure
and to pass an instance of that class into the compiler.
Mark wrote:
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.
Concerning this and the discussion about what parser to use I’d say that
what we really need is to decide on a common AST representation for
Ruby. Then we can have different parser front-ends generating the
correct type of AST and have different analysis and code generation
back-ends.
I’d say that in general though it’s not the design of this or the
parsing that is the hard part; these things are pretty standard in
CS/compiler construction; the hard part is what kind of run-time support
is needed (and of course how you implement it) for Ruby semantics.
BTW, I have two thesis students working (they’ll be starting in 3 weeks
actually) on Ruby compilers, one for compiling to MSIL/CIL and one for
compiling to llvm. Would be great if all these different Ruby compiler
projects could eventually share code although I think it’s too early for
that at this point…
On Slang (Smalltalk subset used in Squeak) and related Ruby ideas you
might wanna check out
and specifically
“SRuby - A Ruby dialect for low-level programming”,
might be a bit dated now but anyway.
Regards,
Robert Feldt
Phil Tomson wrote:
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.
This sounds like a good idea. I guess the first step is to agree on the
AST format to use.
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.
I agree that working out which of these projects to focus on would be useful
–
Mark Sparshatt
Lothar Scholz wrote:
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.
I can’t reproduce this problem. Does it happen consistently? Can you send me
a small sample program to debug and set of steps to reproduce the problem?
Is anyone else having a similar problem, as well??
Thanks,
Curt
Lyle Johnson WROTE:
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
discoveredI 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?
Remember FreeRIDE has always used a private build of Ruby to run itself in
the Windows installation. I don’t remember which version of FXRuby was being
used, but it wasn’t the most recent.
Most likely the fix is because of the upgrade to Ruby 1.8.1. FXRuby was also
updated to the latest version but probably had nothing to do with it. I
didn’t discover this myself because I had only tried the Windows Ruby
Installer version of 1.8.1, under which the FreeRIDE debugger does not
work.
It turns out that the current release of the Windows Ruby Installer has a
few problems that could explain this, and one of my goals (as one of the new
volunteers now working on the Windows Ruby Installer) is to make sure that
the next release of the Windows Ruby Installer fixes these problems.
Curt
Lyle Johnson lyle@knology.net wrote in message news:4043E5F2.3050406@knology.net…
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?
Im not sure whether upgrading to Ruby 1.8.1 ‘fixed’ the problem or if
it was the fact that I compiled it with visual c++ 7.1. The 1.8.1
pragprog installer version of ruby doesnt seem to work.
I say ‘fixed’ because this seems like a really dodgy workaround
Also Lyle, I have a question. Would mixing c++ runtimes cause
problems for ruby’s garbage collector? i.e. if an object is alloc’ed
in FXRuby with the vc++6 runtime then you could potentially get a
crash if ruby free’s it with the vc++7 runtime.
Laza wrote:
I have just downloaded FreeRIDE, and it could not debug. I tried
a console
app, and a GTK app.
Can you be more specific about what happens (especially with the simpler
example of a console app)?
Also, why FreeRIDE does NOT support breakpoints?
Hold down the SHIFT key and click in the left margin to set a breakpoint (a
big red dot will appear on lines that have breakpoints).
Curt
yet, there are places where it may be avoided, say, in tkfont.rb:
obj.instance_eval{ initialize(src) }
maybe could become:
obj.send(:initialize,src)
There should be interest in this kind of changes, apart from
compilation problems?
il 11 Jun 2004 07:59:05 -0700, llothar@web.de (Lothar Scholz) ha scritto::
Nicholas Van Weerdenburg <nick@activehitconsulting.com> wrote in message news:<40C92E6E.9040708@activehitconsulting.com>...
A compiler could attempt to translate evals into other constructs. I
think most are simple enought to do that.No. Simply grep through the 1.8.1 standard library and you see that
it is used a lot in non trivial situations.
Mark Hubbart wrote:
The plan is to write a class that outputs the correct code structure
and to pass an instance of that class into the compiler.That sounds great! Sounds like I have a lot of reading to do…
There’s not too much reading to do at the moment, at least on the
Cardinal front. I’m hoping to make a first, preliminary release over the
weekend which will include an overview of the design as it stands ATM.
Great name, btw.
Yes it is though credit for it goes to Phil Thomson, who first
started the project.
On Feb 28, 2004, at 12:36 AM, Mark wrote:
–
Mark Sparshatt
In article 40406832.1000009@ce.chalmers.se,
Mark wrote:
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.Concerning this and the discussion about what parser to use I’d say that
what we really need is to decide on a common AST representation for
Ruby. Then we can have different parser front-ends generating the
correct type of AST and have different analysis and code generation
back-ends.
Yes, quite true.
I’d say that in general though it’s not the design of this or the
parsing that is the hard part; these things are pretty standard in
CS/compiler construction; the hard part is what kind of run-time support
is needed (and of course how you implement it) for Ruby semantics.
Right, like how do you deal with eval - it should be doable in the runtime
lib.
BTW, I have two thesis students working (they’ll be starting in 3 weeks
actually) on Ruby compilers, one for compiling to MSIL/CIL and one for
compiling to llvm. Would be great if all these different Ruby compiler
projects could eventually share code although I think it’s too early for
that at this point…
That’s great we’ve got grad student slaves working on a Ruby compiler 
But seriously, this sounds like a great time to coordinate efforts. I’m
not sure it’s too early to do that.
BTW: What’s llvm?
On Slang (Smalltalk subset used in Squeak) and related Ruby ideas you
might wanna check out
Data- och informationsteknik
and specifically
“SRuby - A Ruby dialect for low-level programming”,
http://www.ce.chalmers.se/~feldt/ruby/ideas/rubyvm/sruby.pdf
might be a bit dated now but anyway.
Yup, there’s nothing new under the sun.
Phil
Robert Feldt feldt@ce.chalmers.se wrote:
Fascinating read! It answers several of the questions that I had, and
points out problems I hadn’t thought of. It’s giving me lots of food
for thought. Thanks
On Feb 28, 2004, at 2:08 AM, Robert Feldt wrote:
“SRuby - A Ruby dialect for low-level programming”,
http://www.ce.chalmers.se/~feldt/ruby/ideas/rubyvm/sruby.pdf
might be a bit dated now but anyway.
Mark wrote:
Phil Tomson wrote:
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.This sounds like a good idea. I guess the first step is to agree on
the AST format to use.
It was some time since I touched Ruth now but if I remember correctly it
had a fairly complete Ruby AST in there. I propose you at least check it
out…
/Robert
Curt Hibbs wrote:
Lothar Scholz wrote:
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.I can’t reproduce this problem. Does it happen consistently? Can you send me
a small sample program to debug and set of steps to reproduce the problem?Is anyone else having a similar problem, as well??
Yes, I can’t seem to debug any programs in latest FreeRide. Maybe I’m
doing something wrong. Error messages same as Lothars.
/Robert
Hello Curt,
Monday, March 1, 2004, 1:15:38 AM, you wrote:
I can't reproduce this problem. Does it happen consistently? Can you send me
a small sample program to debug and set of steps to reproduce the problem?
I used the file "examples/HelloWorld/hello.rb" from the FreeRIDE distribution.
An this is very reproduceable on my system.
--
Best regards,
Lothar mailto:mailinglists@scriptolutions.com
Mark Watson wrote:
Lyle Johnson lyle@knology.net wrote in message
news:4043E5F2.3050406@knology.net…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?Im not sure whether upgrading to Ruby 1.8.1 ‘fixed’ the problem or if
it was the fact that I compiled it with visual c++ 7.1. The 1.8.1
pragprog installer version of ruby doesnt seem to work.I say ‘fixed’ because this seems like a really dodgy workaround
I didn’t really go into all the details, but there are some good reasons why
1.8.1 would have fixed the problem and (unknown to me at the time) why the
windows installer version does not.
The problem that was preventing the debugger from working under windows was
related to the fact that Windows does not have an equivalent of “fork”
and/or broken support for “popen3”. There was a patch for ruby out of Japan
for the popen problem that (theoretically) should have allowed the debugger
to run – but I was never able to get it work. I imagine that this patch has
been integrated into ruby in the 1.8.1 release.
I tried the windows installer version of 1.8.1, which did not work, so I
concluded that the problem still existed in ruby. But since I started
working on the windows installer project I have run into some anomalies that
suggest that that it might have (inadvertently) been partially built with
cygwin, and this could be a problem for the FreeRIDE debugger.
Curt
Hi
Is there any AST for ruby? in C or ruby?
rolo
Right on. Seems like if it an instance_eval usage can be safely
refactored to something simpler, it'd be a good thing.
Tom
On Fri, 2004-06-11 at 11:08, gabriele renzi wrote:
yet, there are places where it may be avoided, say, in tkfont.rb:
obj.instance_eval{ initialize(src) }
maybe could become:
obj.send(:initialize,src)There should be interest in this kind of changes, apart from
compilation problems?
Would instance_evals (assuming they take blocks) really be that big of a problem? The way I see it, as long as it just takes a code block, that part is compilable; all it takes is a change of the 'self'. But if it takes a String, that must be compiled into code at runtime, and...
cheers,
Mark
On Jun 11, 2004, at 8:08 AM, gabriele renzi wrote:
il 11 Jun 2004 07:59:05 -0700, llothar@web.de (Lothar Scholz) ha
scritto::Nicholas Van Weerdenburg <nick@activehitconsulting.com> wrote in message news:<40C92E6E.9040708@activehitconsulting.com>...
A compiler could attempt to translate evals into other constructs. I
think most are simple enought to do that.No. Simply grep through the 1.8.1 standard library and you see that
it is used a lot in non trivial situations.yet, there are places where it may be avoided, say, in tkfont.rb:
obj.instance_eval{ initialize(src) }
maybe could become:
obj.send(:initialize,src)There should be interest in this kind of changes, apart from
compilation problems?
Mark wrote:
Mark Hubbart wrote:
Great name, btw.
Yes it is
started the project.
Haha… I think he’s referring to the name “Mark.”
Hal