January 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Update] Zinc-SSO now supports Dropbox !

by Sven Van Caekenberghe

On 28 Jan 2013, at 16:23, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: > Cool Sven, nice work :) Thanks, but it is Jan who is the real expert here, having done all this from first principles himself, I am lucky to be able to work with him to bring all this on our platform. > Cheers, > > CÃ©drick > > Le 27 janv. 2013 Ã 13:32, Sven Van Caekenberghe <sven(a)stfx.eu> a Ã©crit : > >> Hi, >> >> I am happy to report that Zinc-SSO now supports the Dropbox API. Which means you can write (web) applications that access (read/write) files in a user's Dropbox account. >> >> Jan extended Zinc-SSO-OAuth1-Core to support both version 1 and version 1a of OAuth1 which I then used for a demo. >> >> Again, the actual setup is non-trivial, and a public demo is not easy either, so there is only this screenshot: >> >> <Screen Shot 2013-01-27 at 13.15.36.png> >> >> This is what you see after allowing the Zinc-SSO app access to a special 'sandbox' folder called Apps/Zinc-SSO (full 'root' Dropbox access is possible as well). Here you can see there is one file, readme.txt in the folder. >> >> If anyone is interested, I can write another email explaining how you can run this demo for yourself on your own account. >> >> Sven >> >> -- >> Sven Van Caekenberghe >> http://stfx.eu >> Smalltalk is the Red Pill >> >

Jan. 28, 2013

Re: [Pharo-project] [Update] Zinc-SSO now supports Dropbox !

by CÃ©drick BÃ©ler

Cool Sven, nice work :) Cheers, CÃ©drick Le 27 janv. 2013 Ã 13:32, Sven Van Caekenberghe <sven(a)stfx.eu> a Ã©crit : > Hi, > > I am happy to report that Zinc-SSO now supports the Dropbox API. Which means you can write (web) applications that access (read/write) files in a user's Dropbox account. > > Jan extended Zinc-SSO-OAuth1-Core to support both version 1 and version 1a of OAuth1 which I then used for a demo. > > Again, the actual setup is non-trivial, and a public demo is not easy either, so there is only this screenshot: > > <Screen Shot 2013-01-27 at 13.15.36.png> > > This is what you see after allowing the Zinc-SSO app access to a special 'sandbox' folder called Apps/Zinc-SSO (full 'root' Dropbox access is possible as well). Here you can see there is one file, readme.txt in the folder. > > If anyone is interested, I can write another email explaining how you can run this demo for yourself on your own account. > > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill >

Jan. 28, 2013

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

by Frank Shearar

On 28 January 2013 15:21, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 28 Jan 2013, at 16:05, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> 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? > > In my experience, Metacello/Monticello caching *is* used (provided you keep using the same package-cache directory). > If you open the Transcript while loading and/or inspect the Metacello loading result, you'll see when the cache is being used. But does that work _transitively_? I was under the impression that it only did if the various ConfigurationOf authors thought to use the package-cache... frank > IMHO, the downloading is not the worst part, it is more the loading/compiling - probably due to massive notifications and the reactions on that, it is hard to analyse and I am no expert at all. > >> 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] How to force Metacello to use the package cache?

by Sven Van Caekenberghe

On 28 Jan 2013, at 16:05, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > 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? In my experience, Metacello/Monticello caching *is* used (provided you keep using the same package-cache directory). If you open the Transcript while loading and/or inspect the Metacello loading result, you'll see when the cache is being used. IMHO, the downloading is not the worst part, it is more the loading/compiling - probably due to massive notifications and the reactions on that, it is hard to analyse and I am no expert at all. > 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

[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