- Pharo-dev - lists.pharo.org

[Pharo-project] How to force Metacello to use the package cache?

by StÃ©phane Ducasse

Hi guys I'm trying to work on Moose and I get 200 package to download during my experiments ~ 30 min at minimum Does anybody have an idea how to make sure metacello use the package cache? I started to comment cacheGofer cacheGofer == nil ifTrue: [ "don't use a caching Gofer here, since we expect the contents to change during a fetch operation" cacheGofer := Gofer new. >>>> cacheGofer disablePackageCache. cacheGofer repository: self cacheRepository. ]. ^ cacheGofer But no success so far. Still looking around Stef

Jan. 28, 2013

Re: [Pharo-project] CouchDB and Pharo

by StÃ©phane Ducasse

Hi guys I would love to have a chapter on couchDB/Mustache/Seaside. I learned also Mustache :) So I contacted jesus and he sent me the source of the tutorial. Now I read it and there is a bit too much js and html to my taste :) So I have several questions: - could we get a chapter on couchDB with less js. - Is there somebody wanted to pair write with me? Because I have time to read and fix and rewrite but not the write the first version. - any other suggestion? - may be get it up to date with the latest JQueryMobile and Pharo jesus I think that it would be good to have some configurationOf for Mustache and SCouch because it will help loading them. Stef > Hi! > > Just noticed your stuff: > > http://vinsicaves.seasidehosting.st/resources/Developing%20Applications%20w… > > http://www.smalltalkhub.com/#!/~jmari/SCouchDBViewServer > > Looks very nice! > > I also wrote a view server implementation a while ago - I remember I did some tricks to make Compiler deal with it properly etc. Can dig it out an email it to you, in that way I am at least sure it didn't go to waste. > > regards, GÃ¶ran > > PS. I moved on to Riak after CouchDB and now I am heavily intrigued by HyperDex and have a binding brewing using NB FFI :) >

Jan. 28, 2013

Re: [Pharo-project] More progress...

by Marcus Denker

On Jan 28, 2013, at 2:53 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Hello, > > In fact IR->AST is useless but if you don't have the pharo sources aside from your vm. > I personally would like to not decompile at allâ¦ we don't have a X86-to-bytecode decompiler either. Instead of decompiling, we should store a high-level representation of the method and use that. We will do that eventually, but people always freak out when I explain that so for now we will make the compiler a drop-in replacement. Marcus

Jan. 28, 2013

Re: [Pharo-project] Fwd: More progress...

by ClÃ©ment Bera

Hello, In fact IR->AST is useless but if you don't have the pharo sources aside from your vm. You right, BC -> IR is kind of a trivial 1 to 1 mapping. But even if it is trivial, it had to be done :) Adding to integration and decompiler, I think the doIt compilation might not be finished too. It is still on the pharo compiler bug tracker. 2013/1/28 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > But isn't BC->IR a trivial 1 to 1 mapping? > IR->AST is the difficult part because of inlining... > But in most cases this should be un-necessary no? > > Indeed, if you get the source code + byte code. > then you can just check integrity like this: > 1) compile source->AST->(IR1->)BC1 > 2) check BC1=BC > ifTrue: [proceed with AST] > ifFalse: [invoke decompiler BC->IR->AST] > > Nicolas > > 2013/1/28 Marcus Denker <marcus.denker(a)inria.fr>: > > â¦ maybe others are interested. > > > > Begin forwarded message: > > > > From: Marcus Denker <marcus.denker(a)inria.fr> > > Subject: More progress... > > Date: January 28, 2013 1:07:19 PM GMT+01:00 > > To: "pharo-compiler(a)lists.gforge.inria.fr" > > <pharo-compiler(a)lists.gforge.inria.fr> > > > > Hi, > > > > Lots of progressâ¦ > > > > -> BC to Text mapping (highlighting in the debugger) > > Instead of building the mapping in the code generator, we instead > > enhanced the AST and IR to have all the right information and > > needed > > mapping. > > > > This means: we can query the AST for "which statement generated the > byte > > code at offset 24?" > > Or "which BlockNode is the one for this Context?". > > > > The AST combined with the Scope/Var annotations and the IR contains > all > > information needed, > > and in cases where something is wrong it is easy to debug. > > > > -> Correct Temp Vars for Contexts (via the Scope/Var knowledge) > > For accessing temps in blocks in the debugger. > > Here we delegate queries to the annotated AST, this means the Debugger > > uses > > the same data structures as the compiler when it wants to know > > about e.g. local temps. > > > > One of the nice effects is that the needed machinery is much simpler: > > > > DebuggerMethodMap linesOfCode 164 > > DebuggerMethodMapOpal linesOfCode 62 > > > > it is actually so simple that in a second step, there is no need for > > DebuggerMethodMapOpal at all, > > the code can be moved directly to better places (e.g. > MethodContext). > > Caching is handled by ASTCache. > > > > -> Error Handling is working. All the error handling (Parsing and > Semantic) > > are handled the same as > > the old compiler. > > > > TODO > > => Pass over integration. Clean up the Compiler/Parser facades. > > (We will first have the whole thing to be compatible to the old from > > the Compiler/Parser POV, > > here more cleanups are following after we have the stuff in > > the image) > > > > => Pass over the decompiler. BC->IR is working, IR->AST needs to be > checked. > > > > => Fix all showstoppers here: > > http://code.google.com/p/pharo-newcompiler/issues/list > > > > > > Marcus and Clement > > > > > >

Jan. 28, 2013

[Pharo-project] FOSDEM diner & drinks?

by Stephan Eggermont

Hi, Craig and I plan to arrive in Brussels-Midi 12:04 on saturday. We are up for diner & drinks saturday evening, and early diner on sunday. We'd like to travel back to the Netherlands at 19.00 or so. Any ideas? I liked the place Andy showed us last year, and it is perfect for sunday evening. Cheers, Stephan

Jan. 28, 2013

Re: [Pharo-project] Fwd: More progress...

by Nicolas Cellier

But isn't BC->IR a trivial 1 to 1 mapping? IR->AST is the difficult part because of inlining... But in most cases this should be un-necessary no? Indeed, if you get the source code + byte code. then you can just check integrity like this: 1) compile source->AST->(IR1->)BC1 2) check BC1=BC ifTrue: [proceed with AST] ifFalse: [invoke decompiler BC->IR->AST] Nicolas 2013/1/28 Marcus Denker <marcus.denker(a)inria.fr>: > â¦ maybe others are interested. > > Begin forwarded message: > > From: Marcus Denker <marcus.denker(a)inria.fr> > Subject: More progress... > Date: January 28, 2013 1:07:19 PM GMT+01:00 > To: "pharo-compiler(a)lists.gforge.inria.fr" > <pharo-compiler(a)lists.gforge.inria.fr> > > Hi, > > Lots of progressâ¦ > > -> BC to Text mapping (highlighting in the debugger) > Instead of building the mapping in the code generator, we instead > enhanced the AST and IR to have all the right information and > needed > mapping. > > This means: we can query the AST for "which statement generated the byte > code at offset 24?" > Or "which BlockNode is the one for this Context?". > > The AST combined with the Scope/Var annotations and the IR contains all > information needed, > and in cases where something is wrong it is easy to debug. > > -> Correct Temp Vars for Contexts (via the Scope/Var knowledge) > For accessing temps in blocks in the debugger. > Here we delegate queries to the annotated AST, this means the Debugger > uses > the same data structures as the compiler when it wants to know > about e.g. local temps. > > One of the nice effects is that the needed machinery is much simpler: > > DebuggerMethodMap linesOfCode 164 > DebuggerMethodMapOpal linesOfCode 62 > > it is actually so simple that in a second step, there is no need for > DebuggerMethodMapOpal at all, > the code can be moved directly to better places (e.g. MethodContext). > Caching is handled by ASTCache. > > -> Error Handling is working. All the error handling (Parsing and Semantic) > are handled the same as > the old compiler. > > TODO > => Pass over integration. Clean up the Compiler/Parser facades. > (We will first have the whole thing to be compatible to the old from > the Compiler/Parser POV, > here more cleanups are following after we have the stuff in > the image) > > => Pass over the decompiler. BC->IR is working, IR->AST needs to be checked. > > => Fix all showstoppers here: > http://code.google.com/p/pharo-newcompiler/issues/list > > > Marcus and Clement > >

Jan. 28, 2013

[Pharo-project] [Issue Tracker] Failing Tests in 2.0

by Marcus Denker

Failing test in 2.0: http://code.google.com/p/pharo/issues/list?can=2&q=milestone=2.0%20status=F… I added all failing tests from Jenkins to the tracker. https://ci.inria.fr/pharo/view/Pharo-2.0/job/Pharo-2.0-Tests/

Jan. 28, 2013

Re: [Pharo-project] Fwd: More progress...

by Fernando Olivero

Hi Marcus, this are great news! For the less-knowledgable in OPAL, were can we read more about it? Fernando On Mon, Jan 28, 2013 at 1:15 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Yes ! > > Looking forward to itâ¦ > > On 28 Jan 2013, at 13:09, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > â¦ maybe others are interested. > > > > Begin forwarded message: > > > >> From: Marcus Denker <marcus.denker(a)inria.fr> > >> Subject: More progress... > >> Date: January 28, 2013 1:07:19 PM GMT+01:00 > >> To: "pharo-compiler(a)lists.gforge.inria.fr" < > pharo-compiler(a)lists.gforge.inria.fr> > >> > >> Hi, > >> > >> Lots of progressâ¦ > >> > >> -> BC to Text mapping (highlighting in the debugger) > >> Instead of building the mapping in the code generator, we > instead > >> enhanced the AST and IR to have all the right information > and needed > >> mapping. > >> > >> This means: we can query the AST for "which statement > generated the byte code at offset 24?" > >> Or "which BlockNode is the one for this Context?". > >> > >> The AST combined with the Scope/Var annotations and the IR > contains all information needed, > >> and in cases where something is wrong it is easy to debug. > >> > >> -> Correct Temp Vars for Contexts (via the Scope/Var knowledge) > >> For accessing temps in blocks in the debugger. > >> Here we delegate queries to the annotated AST, this means the > Debugger uses > >> the same data structures as the compiler when it wants to > know about e.g. local temps. > >> > >> One of the nice effects is that the needed machinery is much > simpler: > >> > >> DebuggerMethodMap linesOfCode 164 > >> DebuggerMethodMapOpal linesOfCode 62 > >> > >> it is actually so simple that in a second step, there is no need > for DebuggerMethodMapOpal at all, > >> the code can be moved directly to better places (e.g. > MethodContext). Caching is handled by ASTCache. > >> > >> -> Error Handling is working. All the error handling (Parsing and > Semantic) are handled the same as > >> the old compiler. > >> > >> TODO > >> => Pass over integration. Clean up the Compiler/Parser facades. > >> (We will first have the whole thing to be compatible to the > old from the Compiler/Parser POV, > >> here more cleanups are following after we have the stuff > in the image) > >> > >> => Pass over the decompiler. BC->IR is working, IR->AST needs to > be checked. > >> > >> => Fix all showstoppers here: > http://code.google.com/p/pharo-newcompiler/issues/list > >> > >> > >> Marcus and Clement > >> > > > > >

Jan. 28, 2013

Re: [Pharo-project] Fwd: More progress...

by Sven Van Caekenberghe

Yes ! Looking forward to itâ¦ On 28 Jan 2013, at 13:09, Marcus Denker <marcus.denker(a)inria.fr> wrote: > â¦ maybe others are interested. > > Begin forwarded message: > >> From: Marcus Denker <marcus.denker(a)inria.fr> >> Subject: More progress... >> Date: January 28, 2013 1:07:19 PM GMT+01:00 >> To: "pharo-compiler(a)lists.gforge.inria.fr" <pharo-compiler(a)lists.gforge.inria.fr> >> >> Hi, >> >> Lots of progressâ¦ >> >> -> BC to Text mapping (highlighting in the debugger) >> Instead of building the mapping in the code generator, we instead >> enhanced the AST and IR to have all the right information and needed >> mapping. >> >> This means: we can query the AST for "which statement generated the byte code at offset 24?" >> Or "which BlockNode is the one for this Context?". >> >> The AST combined with the Scope/Var annotations and the IR contains all information needed, >> and in cases where something is wrong it is easy to debug. >> >> -> Correct Temp Vars for Contexts (via the Scope/Var knowledge) >> For accessing temps in blocks in the debugger. >> Here we delegate queries to the annotated AST, this means the Debugger uses >> the same data structures as the compiler when it wants to know about e.g. local temps. >> >> One of the nice effects is that the needed machinery is much simpler: >> >> DebuggerMethodMap linesOfCode 164 >> DebuggerMethodMapOpal linesOfCode 62 >> >> it is actually so simple that in a second step, there is no need for DebuggerMethodMapOpal at all, >> the code can be moved directly to better places (e.g. MethodContext). Caching is handled by ASTCache. >> >> -> Error Handling is working. All the error handling (Parsing and Semantic) are handled the same as >> the old compiler. >> >> TODO >> => Pass over integration. Clean up the Compiler/Parser facades. >> (We will first have the whole thing to be compatible to the old from the Compiler/Parser POV, >> here more cleanups are following after we have the stuff in the image) >> >> => Pass over the decompiler. BC->IR is working, IR->AST needs to be checked. >> >> => Fix all showstoppers here: http://code.google.com/p/pharo-newcompiler/issues/list >> >> >> Marcus and Clement >> >

Jan. 28, 2013

[Pharo-project] Fwd: More progress...

by Marcus Denker

â¦ maybe others are interested. Begin forwarded message: > From: Marcus Denker <marcus.denker(a)inria.fr> > Subject: More progress... > Date: January 28, 2013 1:07:19 PM GMT+01:00 > To: "pharo-compiler(a)lists.gforge.inria.fr" <pharo-compiler(a)lists.gforge.inria.fr> > > Hi, > > Lots of progressâ¦ > > -> BC to Text mapping (highlighting in the debugger) > Instead of building the mapping in the code generator, we instead > enhanced the AST and IR to have all the right information and needed > mapping. > > This means: we can query the AST for "which statement generated the byte code at offset 24?" > Or "which BlockNode is the one for this Context?". > > The AST combined with the Scope/Var annotations and the IR contains all information needed, > and in cases where something is wrong it is easy to debug. > > -> Correct Temp Vars for Contexts (via the Scope/Var knowledge) > For accessing temps in blocks in the debugger. > Here we delegate queries to the annotated AST, this means the Debugger uses > the same data structures as the compiler when it wants to know about e.g. local temps. > > One of the nice effects is that the needed machinery is much simpler: > > DebuggerMethodMap linesOfCode 164 > DebuggerMethodMapOpal linesOfCode 62 > > it is actually so simple that in a second step, there is no need for DebuggerMethodMapOpal at all, > the code can be moved directly to better places (e.g. MethodContext). Caching is handled by ASTCache. > > -> Error Handling is working. All the error handling (Parsing and Semantic) are handled the same as > the old compiler. > > TODO > => Pass over integration. Clean up the Compiler/Parser facades. > (We will first have the whole thing to be compatible to the old from the Compiler/Parser POV, > here more cleanups are following after we have the stuff in the image) > > => Pass over the decompiler. BC->IR is working, IR->AST needs to be checked. > > => Fix all showstoppers here: http://code.google.com/p/pharo-newcompiler/issues/list > > > Marcus and Clement >

Jan. 28, 2013