From surrender_it at yahoo.it Fri Jul 1 03:35:25 2005 From: surrender_it at yahoo.it (gabriele renzi) Date: Fri Jul 1 03:30:34 2005 Subject: [Yarv-devel] OOPSLA Poster Abstract In-Reply-To: <42C4BFA4.5050004@atdot.net> Message-ID: <20050701073526.35536.qmail@web26208.mail.ukl.yahoo.com> --- SASADA Koichi wrote: > Hi, > > Thanks a lot, everyone. > > I fixed extended abstarct. > > It's RC1. > http://www.atdot.net/yarv/oopsla2005eabstract-rc1.pdf > http://www.atdot.net/yarv/oopsla2005eabstract-rc1.tex > > I'll post it by the end of today. mh.. three things: tiny error, section 2.3: "In this case, method + is compiled to the spezialized specialised instruction opt_plus" I think "specialized" is enough :) Two typos in section 4: "I am planning to desgin Multi-VM instances mechanism like Java Multi-Talking VM". You wrote desgin instead of design and Talking instead of Tasking. Hope this helps. icq #69488917 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From ko1 at atdot.net Fri Jul 1 03:59:06 2005 From: ko1 at atdot.net (SASADA Koichi) Date: Fri Jul 1 03:55:00 2005 Subject: [Yarv-devel] OOPSLA Poster Abstract In-Reply-To: <20050701073526.35536.qmail@web26208.mail.ukl.yahoo.com> References: <20050701073526.35536.qmail@web26208.mail.ukl.yahoo.com> Message-ID: <42C4F7CA.2030600@atdot.net> Hi, gabriele renzi wrote: > mh.. three things: > > tiny error, section 2.3: > "In this case, method + is compiled to > the spezialized specialised instruction opt_plus" > > I think "specialized" is enough :) > > Two typos in section 4: > "I am planning to desgin Multi-VM instances mechanism > like Java Multi-Talking VM". > You wrote desgin instead of design and Talking instead > of Tasking. Yeeeees. Thank you very much. BTW, what is the Multi-Talking VM? :-p (noisy?) -- // SASADA Koichi at atdot dot net // From drbrain at segment7.net Fri Jul 1 04:54:39 2005 From: drbrain at segment7.net (Eric Hodel) Date: Fri Jul 1 04:49:53 2005 Subject: [Yarv-devel] OOPSLA Poster Abstract In-Reply-To: <42C4F7CA.2030600@atdot.net> References: <20050701073526.35536.qmail@web26208.mail.ukl.yahoo.com> <42C4F7CA.2030600@atdot.net> Message-ID: <2BEF1453-4AAB-4277-BF94-93FDB4B89B6E@segment7.net> On 01 Jul 2005, at 00:59, SASADA Koichi wrote: > BTW, what is the Multi-Talking VM? :-p > (noisy?) It is a nonsense phrase, but noisy comes to mind. -- Eric Hodel - drbrain@segment7.net - http://segment7.net FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04 From vincent.isambart at gmail.com Fri Jul 1 05:13:43 2005 From: vincent.isambart at gmail.com (Vincent Isambart) Date: Fri Jul 1 05:08:52 2005 Subject: [Yarv-devel] OOPSLA Poster Abstract In-Reply-To: <42C4BFA4.5050004@atdot.net> References: <42BFE516.5030904@atdot.net> <200506271537.06027.mneumann@ntecs.de> <42C16D5B.6060701@atdot.net> <42C23556.6030706@amelang.net> <42C4BFA4.5050004@atdot.net> Message-ID: <7d9a1f53050701021362abc88e@mail.gmail.com> Hi, Here is a diff with a few corrections (I included the errors pointed out by Gabriele). If someone else could check my corrections it would be even better :). Cheers, Vincent Isambart -------------- next part -------------- 52c52 < Ruby has following characteristics. --- > Ruby has the following characteristics: 69,71c69,71 < However, current Ruby intepreter is slow. This is because current < interpreter (old-ruby) works by traversing abstract syntax tree and < evaluates each node. To solve this problem, I have developed new Ruby --- > However, the current Ruby intepreter (old-ruby) is slow. This is because > it works by traversing abstract syntax tree and > evaluating each node. To solve this problem, I have developed a new Ruby 73,74c73,74 < and runs Ruby programs in compiled intemediate representation of < sequential instructions. I'm working to replacing old-ruby with YARV. --- > and runs Ruby programs in compiled intermediate representation of > sequential instructions. I'm working on replacing old-ruby with YARV. 98c98 < YARV currently works on Linux with GCC and Windows2000/XP with Visual --- > YARV currently works on Linux with GCC and Windows 2000/XP with Visual 146c146 < method \verb|+| is sent to reciever \verb|1| with an argument \verb|2|). --- > method \verb|+| is sent to receiver \verb|1| with an argument \verb|2|). 149c149 < spezialized specialised instruction \verb|opt_plus|. \verb|opt_plus| --- > specialized instruction \verb|opt_plus|. \verb|opt_plus| 164c164 < caching instructions and translater for compilation. --- > caching instructions and translator for compilation. 208c208 < native threads (Operating System managed it). This will enable Ruby --- > native threads (managed by the Operating System). This will enable Ruby 211,212c211,212 < Also I am planning to desgin Multi-VM instances mechanism like Java < Multi-Talking VM\cite{java-mvm}. This will improve performance and --- > I also plan to design Multi-VM instances mechanism like Java > Multi-Tasking VM\cite{java-mvm}. This will improve performance and 215,216c215,216 < Ultimately, I will replace current Ruby interpreter with YARV and YARV < becomes The Ruby Virtual Machine. --- > Ultimately, I will replace the current Ruby interpreter with YARV and YARV > will become The Ruby Virtual Machine. 224c224 < I want to address of thanks to Michael Neumann, Daniel Amelang, --- > I want to address thanks to Michael Neumann, Daniel Amelang, From ko1 at atdot.net Wed Jul 6 08:44:12 2005 From: ko1 at atdot.net (SASADA Koichi) Date: Wed Jul 6 08:40:02 2005 Subject: [Yarv-devel] OOPSLA Poster Abstract In-Reply-To: <7d9a1f53050701021362abc88e@mail.gmail.com> References: <42BFE516.5030904@atdot.net> <200506271537.06027.mneumann@ntecs.de> <42C16D5B.6060701@atdot.net> <42C23556.6030706@amelang.net> <42C4BFA4.5050004@atdot.net> <7d9a1f53050701021362abc88e@mail.gmail.com> Message-ID: <42CBD21C.50501@atdot.net> Hi, Thanks a lot everyone! I submitted it, and I can only pray to be accepted it. Thanks, -- // SASADA Koichi at atdot dot net // From ko1 at atdot.net Wed Jul 6 09:05:40 2005 From: ko1 at atdot.net (SASADA Koichi) Date: Wed Jul 6 09:01:29 2005 Subject: [Yarv-devel] RubyConf2005 Message-ID: <42CBD724.7080004@atdot.net> Hi, My presentation in RubyConf2005 was accepted! But maybe I can't talk 1 hour... What should I show...? (So I proposed short time presentation.) If you have any topic about YARV which you want to listen, please teach me. BTW, every topics (except mine, because I know everything I can talk) is very interesting. Regards, -- // SASADA Koichi at atdot dot net // From surrender_it at yahoo.it Wed Jul 6 09:38:33 2005 From: surrender_it at yahoo.it (gabriele renzi) Date: Wed Jul 6 09:33:33 2005 Subject: [Yarv-devel] RubyConf2005 In-Reply-To: <42CBD724.7080004@atdot.net> Message-ID: <20050706133833.22293.qmail@web26203.mail.ukl.yahoo.com> --- SASADA Koichi wrote: > Hi, > > My presentation in RubyConf2005 was accepted! > > > But maybe I can't talk 1 hour... What should I > show...? well, I won't partecipate at RubyConf but It would be interesting to know your ideas on the parts of yarv that are not developed yet, i.e. - how to handle native threading in a portable fashion, what API will it preovide in ruby land, interpreter locking etc and if it would take advantage of the new SMT/CMT CPUs - jitting: would'nt the ruby interpreter become too big/hard to mantain, and if there are ways to avoid this icq #69488917 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From ko1 at atdot.net Wed Jul 6 12:31:48 2005 From: ko1 at atdot.net (SASADA Koichi) Date: Wed Jul 6 12:27:39 2005 Subject: [Yarv-devel] RubyConf2005 In-Reply-To: <20050706133833.22293.qmail@web26203.mail.ukl.yahoo.com> References: <20050706133833.22293.qmail@web26203.mail.ukl.yahoo.com> Message-ID: <42CC0774.3020905@atdot.net> Hi, > well, I won't partecipate at RubyConf but It would be It's toooo sad news. > interesting to know your ideas on the parts of yarv > that are not developed yet, i.e. > - how to handle native threading in a portable > fashion, what API will it preovide in ruby land, > interpreter locking etc and if it would take advantage > of the new SMT/CMT CPUs OK. In fact, I want to know it :) And I'll only support pthread and Win32 Thread. Otherwise only userlevel thread will be supported. > - jitting: would'nt the ruby interpreter become too > big/hard to mantain, and if there are ways to avoid > this Maybe I doesn't plan to make JIT compiler in this year. But I'll use a technique of selective inlining (*1) or dynamic superinstruction (*2). *1: http://citeseer.ist.psu.edu/piumarta98optimizing.html *2: http://citeseer.ist.psu.edu/ertl03optimizing.html Thanks, -- // SASADA Koichi at atdot dot net // From ko1 at atdot.net Thu Jul 7 11:16:34 2005 From: ko1 at atdot.net (SASADA Koichi) Date: Thu Jul 7 11:12:31 2005 Subject: [Yarv-devel] [ANN] YARV 0.2.1 Message-ID: <42CD4752.1010900@atdot.net> Hi, I released YARV 0.2.1 (Tanabata release). Changes: http://www.atdot.net/svn/yarv/trunk/Changes Tanabata: http://www.japan-guide.com/e/e2283.html Regars, -- // SASADA Koichi at atdot dot net // From vincent.isambart at gmail.com Thu Jul 7 11:30:13 2005 From: vincent.isambart at gmail.com (Vincent Isambart) Date: Thu Jul 7 11:25:23 2005 Subject: [Yarv-devel] [ANN] YARV 0.2.1 In-Reply-To: <42CD4752.1010900@atdot.net> References: <42CD4752.1010900@atdot.net> Message-ID: <7d9a1f53050707083036c8b52e@mail.gmail.com> Hi, > I released YARV 0.2.1 (Tanabata release). Where can we download it (without using CVS)? Cheers, Vincent ISAMBART From ko1 at atdot.net Thu Jul 7 11:54:58 2005 From: ko1 at atdot.net (SASADA Koichi) Date: Thu Jul 7 11:51:03 2005 Subject: [Yarv-devel] [ANN] YARV 0.2.1 In-Reply-To: <7d9a1f53050707083036c8b52e@mail.gmail.com> References: <42CD4752.1010900@atdot.net> <7d9a1f53050707083036c8b52e@mail.gmail.com> Message-ID: <42CD5052.6080601@atdot.net> Hi, Vincent Isambart wrote: > Where can we download it (without using CVS)? You can downlaod YARV 0.2.1 with Subversion: svn co http://www.atdot.net/svn/yarv/tags/0.2.1 Or you can download YARV latest version and each revision via http: http://www.atdot.net/~ko1/archive/ I'll update web page (http://www.atdot.net/yarv) and make tarball tomorrow. Regards, -- // SASADA Koichi at atdot dot net // From ko1 at atdot.net Fri Jul 29 04:49:47 2005 From: ko1 at atdot.net (SASADA Koichi) Date: Fri Jul 29 04:45:06 2005 Subject: [Yarv-devel] backtrace format Message-ID: <42E9EDAB.1000503@atdot.net> Hi, I'm writing a backtrace function. --------------------------------------------- def m enum enum.map{ yield } end begin m(1..3){ raise } rescue => e puts e.backtrace end ------------------------------------------- on above program, each backtrace is follows: YARV:------------------------ ../test.rb:19:in `raise' ../test.rb:19:in `b@
' ../test.rb:13:in `b@m' ../test.rb:12:in `each' ../test.rb:12:in `map' ../test.rb:12:in `m' ../test.rb:18:in `
' Ruby:------------------------ ../test.rb:19 ../test.rb:18:in `m' ../test.rb:12:in `map' <---- (*) ../test.rb:12:in `each' ../test.rb:12:in `map' ../test.rb:12:in `m' ../test.rb:18 ------------------------------------------- In YARV backtrace notation, following points are different to ruby's. 1)
as top level 2) "b@..." means block in "..." 3) eliminate (*) part this stack frame is for C block (NODE_IFUNC) 4) "raise" stack frame is shown 4) will be vanished (it's temporalily). What do you think about other points? YARV should make ruby's backtrace notation? -- // SASADA Koichi at atdot dot net // From vincent.isambart at gmail.com Fri Jul 29 05:26:36 2005 From: vincent.isambart at gmail.com (Vincent Isambart) Date: Fri Jul 29 05:20:54 2005 Subject: [Yarv-devel] backtrace format In-Reply-To: <42E9EDAB.1000503@atdot.net> References: <42E9EDAB.1000503@atdot.net> Message-ID: <7d9a1f5305072902263527b30@mail.gmail.com> Hi, > What do you think about other points? YARV should make ruby's backtrace > notation? I think showing that we are in a block may be a good thing, but I am not sure about the 'b@' notation. I think simply putting "block in " would be better :-). In this mail you did explain what 'b@' meant but not everyone will guess at least at first sight. For the
thing, I do not know but it's true that you need to reference the top level by a name, especially for the "block in". But maybe "" would be better ;-). For the (*) line, I think it's better without it. I am not even sure why ruby puts it... So with my thoughts it gives us: (I also moved the ` but I'm not sure about that) ../test.rb:19:in `raise' ../test.rb:19:in block in `' ../test.rb:13:in block in `m' ../test.rb:12:in `each' ../test.rb:12:in `map' ../test.rb:12:in `m' ../test.rb:18:in `' I think it looks slightly better for a programmer than the ruby one... Maybe "`'" should be just "top level" or "" (without the `')... The only problem is if some programs use the content returned by the backtrace function, but I do not think it's a big problem. What do you think? But you should also maybe ask Matz, just to be sure he agrees with changing the backtrace ;-). Cheers, Vincent From ko1 at atdot.net Fri Jul 29 05:43:36 2005 From: ko1 at atdot.net (SASADA Koichi) Date: Fri Jul 29 05:38:54 2005 Subject: [Yarv-devel] backtrace format In-Reply-To: <7d9a1f5305072902263527b30@mail.gmail.com> References: <42E9EDAB.1000503@atdot.net> <7d9a1f5305072902263527b30@mail.gmail.com> Message-ID: <42E9FA48.2020909@atdot.net> Hi, Thank you for your comments. I implemented. ----------------------- def iter yield end begin iter{ iter{ iter{ raise } } } rescue => e puts e.backtrace end ----------------------- #=> ../test.rb:19:in `raise' ../test.rb:19:in `block in block in block in ' ../test.rb:12:in `iter' ../test.rb:18:in `block in block in ' ../test.rb:12:in `iter' ../test.rb:17:in `block in ' ../test.rb:12:in `iter' ../test.rb:16:in `' Is it too verbosy? -- // SASADA Koichi at atdot dot net // From daniel.amelang at gmail.com Fri Jul 29 06:22:37 2005 From: daniel.amelang at gmail.com (Daniel Amelang) Date: Fri Jul 29 06:16:55 2005 Subject: [Yarv-devel] backtrace format In-Reply-To: <42E9FA48.2020909@atdot.net> References: <42E9EDAB.1000503@atdot.net> <7d9a1f5305072902263527b30@mail.gmail.com> <42E9FA48.2020909@atdot.net> Message-ID: I like it. You could avoid the 'block in block in block in' thing with a simple 'block (3 deep) in' or 'block in (3x)' or 'block (3 levels) in' or something like it. While you're looking at backtraces I'm sure you've seen the sydney approach to backtraces:: http://blog.fallingsnow.net/articles/2005/07/11/sydney-developer-preview-release-1-out which was well received. Something to consider. Dan From ko1 at atdot.net Fri Jul 29 06:42:52 2005 From: ko1 at atdot.net (SASADA Koichi) Date: Fri Jul 29 06:38:11 2005 Subject: [Yarv-devel] backtrace format In-Reply-To: References: <42E9EDAB.1000503@atdot.net> <7d9a1f5305072902263527b30@mail.gmail.com> <42E9FA48.2020909@atdot.net> Message-ID: <42EA082C.4010902@atdot.net> Hi, Daniel Amelang wrote: > I like it. You could avoid the 'block in block in block in' thing with > a simple 'block (3 deep) in' or 'block in (3x)' or 'block (3 levels) > in' or something like it. I try it. def iter yield end begin iter{ iter{ iter{ raise } } } rescue => e puts e.backtrace end #=> ../test.rb:19:in `raise' ../test.rb:19:in `block (3 levels) in
' ../test.rb:12:in `iter' ../test.rb:18:in `block (2 levels) in
' ../test.rb:12:in `iter' ../test.rb:17:in `block in
' ../test.rb:12:in `iter' ../test.rb:16:in `
' How about it? > While you're looking at backtraces I'm sure you've seen the sydney > approach to backtraces:: > > http://blog.fallingsnow.net/articles/2005/07/11/sydney-developer-preview-release-1-out > > which was well received. Something to consider. I have only viewed it. Could you show me sample one? -- // SASADA Koichi at atdot dot net // From matju at artengine.ca Sat Jul 30 23:01:45 2005 From: matju at artengine.ca (Mathieu Bouchard) Date: Sat Jul 30 22:55:20 2005 Subject: [Yarv-devel] backtrace format In-Reply-To: <42EA082C.4010902@atdot.net> References: <42E9EDAB.1000503@atdot.net> <7d9a1f5305072902263527b30@mail.gmail.com> <42E9FA48.2020909@atdot.net> <42EA082C.4010902@atdot.net> Message-ID: On Fri, 29 Jul 2005, SASADA Koichi wrote: > ../test.rb:19:in `raise' > ../test.rb:19:in `block (3 levels) in
' > ../test.rb:12:in `iter' > ../test.rb:18:in `block (2 levels) in
' > ../test.rb:12:in `iter' > ../test.rb:17:in `block in
' > ../test.rb:12:in `iter' > ../test.rb:16:in `
' > How about it? I'd rather have this: > ../test.rb:19:in `raise' > ../test.rb:19:in `block#3 in
' > ../test.rb:12:in `iter' > ../test.rb:18:in `block#2 in
' > ../test.rb:12:in `iter' > ../test.rb:17:in `block#1 in
' > ../test.rb:12:in `iter' > ../test.rb:16:in `
' So that if I write: iter{a;iter{b;iter{c};iter{d}};iter{e;iter{f};iter{g}}} Those get numbered from #1 to #7 so that I know which one the error was in. The block numbers are relative to the position of the left-brace (or of the "do") ____________________________________________________________________ Mathieu Bouchard - t?l:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montr?al QC Canada From surrender_it at yahoo.it Sun Jul 31 14:30:46 2005 From: surrender_it at yahoo.it (gabriele renzi) Date: Sun Jul 31 14:24:59 2005 Subject: [Yarv-devel] backtrace format In-Reply-To: Message-ID: <20050731183046.83414.qmail@web26208.mail.ukl.yahoo.com> > On Fri, 29 Jul 2005, SASADA Koichi wrote: > ../test.rb:19:in `raise' > ../test.rb:19:in `block (3 levels) in
' > ../test.rb:12:in `iter' > ../test.rb:18:in `block (2 levels) in
' > ../test.rb:12:in `iter' > ../test.rb:17:in `block in
' > ../test.rb:12:in `iter' > ../test.rb:16:in `
' > How about it? it's nice, imho. And, while we're talking about backtraces, what about the idea outlined here[1]? It is basically about adding argument informations to the backtrace i.e. replacing from /foo.rb:18:in `bar' with from /foo.rb:18:in `bar(10, nil)' I think this would be a really nice help to easily spot problems, but I don't know how it would impact on the VM performance. [1]http://pezra.barelyenough.org/blog/2005/04/ruby-backtraces/ icq #69488917 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From ko1 at atdot.net Sun Jul 31 21:56:16 2005 From: ko1 at atdot.net (SASADA Koichi) Date: Sun Jul 31 21:51:51 2005 Subject: [Yarv-devel] backtrace format In-Reply-To: <20050731183046.83414.qmail@web26208.mail.ukl.yahoo.com> References: <20050731183046.83414.qmail@web26208.mail.ukl.yahoo.com> Message-ID: <42ED8140.1050209@atdot.net> Hi, gabriele renzi wrote: > And, while we're talking about backtraces, what about > the idea outlined here[1]? > > It is basically about adding argument informations to > the backtrace i.e. replacing > from /foo.rb:18:in `bar' > with > from /foo.rb:18:in `bar(10, nil)' > > I think this would be a really nice help to easily > spot problems, but I don't know how it would impact on > the VM performance. > > [1]http://pezra.barelyenough.org/blog/2005/04/ruby-backtraces/ I think it's difficult to implement. Because object.inspect can cause exception. Of course, there is big impact on VM performance. -- // SASADA Koichi at atdot dot net //