- Pharo-dev - lists.pharo.org

Re: [Pharo-project] scripting a package backup

by jannik.laval

Hi Lukas, What I need is the information stored in the Monticello objects (I do not know which one for now). I would like to do something like that: === Gofer new url: (MCSomething new: myPackage) projectUrl; version: currentVersion; fetch Gofer new directory: myDirectory; package: myPackage; push === Do you know how to get the Monticello distant url of a package ? and to get the current version ? I saw that the Monticello GUI does it. Thank you Jannik On Nov 18, 2011, at 22:07 , Lukas Renggli wrote: > On 18 November 2011 21:40, jannik.laval <jannik.laval(a)gmail.com> wrote: >> My point is that I do not want to know the remote repository. >> I just want to copy my current package on a local repository. >> >> When you write squeaksource: 'remote', you suppose that your package is on squeaksource in the project named remote. >> That is that information that I do not want to give. > > Everything that is not your package cache is remote. It can also be a > directory on your HD, a GOODS database, or whatever ... > >> I need the process that creates the mcz file, to copy it on a repository. > > I do not get it. Maybe you want to give more context? > >> Jannik >> >> On Nov 18, 2011, at 18:37 , Lukas Renggli wrote: >> >>> On 18 November 2011 16:11, jannik.laval <jannik.laval(a)gmail.com> wrote: >>>> Yes, that is my problem ! >>>> I want to export packages in a repository outside the package cache and with an empty package cache. >>>> The problem to pull the version first, is to know the url of the version. >>> >>> I don't get your problem! >>> >>> Gofer new >>> squeaksource: 'remote'; >>> version: 'Foo-123'; " or package: 'Foo' if you want >>> all version " >>> fetch >>> >>> Gofer new >>> squeaksource: 'backup'; >>> version: 'Foo-123'; >>> push >>> >>> >>> >>>> >>>> Jannik >>>> >>>> On Nov 18, 2011, at 16:03 , Lukas Renggli wrote: >>>> >>>>> It is all relative to your package cache, so maybe you have to pull >>>>> the versions first? >>>>> >>>>> On 18 November 2011 10:53, jannik.laval <jannik.laval(a)gmail.com> wrote: >>>>>> Hi Lukas, >>>>>> I tried: >>>>>> >>>>>> === >>>>>> RPackageOrganizer packageInfoNames do:[:e | >>>>>> Gofer new >>>>>> directory: '/Users/janniklaval/Desktop/MCPackages'; >>>>>> package: e; >>>>>> push. >>>>>> ] >>>>>> === >>>>>> but if the package was not modified, it does not copy the source files. >>>>>> >>>>>> Jannik >>>>>> >>>>>> On Nov 18, 2011, at 10:38 , Lukas Renggli wrote: >>>>>> >>>>>>> It would be trivial with Gofer: >>>>>>> >>>>>>> Gofer new >>>>>>> squeaksource: 'backupproject'; >>>>>>> package: 'P1'; >>>>>>> package: 'P2'; >>>>>>> package: 'P3'; >>>>>>> push >>>>>>> >>>>>>> Now of course you can find your script a working script in the class GoferPush. >>>>>>> >>>>>>> Lukas >>>>>>> >>>>>>> On 18 November 2011 10:03, jannik.laval <jannik.laval(a)gmail.com> wrote: >>>>>>>> Hi Pharoers, >>>>>>>> >>>>>>>> I would like to backup my packages in a repository with a script. >>>>>>>> I have one constraint: I need to use Monticello (eg, not gofer or metacello). >>>>>>>> And I do not want to have a version incrementation. >>>>>>>> >>>>>>>> Does someone have any script or any way to do that ? >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Jannik >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Lukas Renggli >>>>>>> www.lukas-renggli.ch >>>>>>> >>>>>> >>>>>> --- >>>>>> Jannik Laval >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Lukas Renggli >>>>> www.lukas-renggli.ch >>>>> >>>> >>>> --- >>>> Jannik Laval >>>> >>>> >>>> >>> >>> >>> >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >>> >> >> --- >> Jannik Laval >> >> >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > --- Jannik Laval

Nov. 21, 2011

Re: [Pharo-project] Startup Preferences

by Damien Cassou

Very good idea indeed. I'm just concerned about the directory location: On Sat, Nov 19, 2011 at 2:13 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > ~/.pharo#{version} what about using the freedesktop.org specification of using $HOME/.config to put configuration files? What about having the #{version} as a subdirectory? That would result in something like: ~/.config/pharo/#{version}/ Also, it could be interesting to load all files in ~/.config/pharo/general/, whatever the version of Pharo. This would be useful to set passwords for example. The specification is at http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html#vari… -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Nov. 21, 2011

Re: [Pharo-project] #ifCurtailed:

by Igor Stasenko

On 20 November 2011 16:19, Philippe Marschall <kustos(a)gmx.net> wrote: > Hi > > Am I right that the argument to #ifCurtailed: is run in a different process > (like #ensure: in an exception case)? > not necessary. A non-local returns are also trapped by it: [ ^ xx ] ifCurtailed: [ ... ] > Cheers > Philippe > > > -- Best regards, Igor Stasenko.

Nov. 21, 2011

[Pharo-project] [update 1.4] #14233

by StÃ©phane Ducasse

14233 ----- - Issue 5004: Decompiler miss-initialize the Encoder literalStream with a ReadStream when a WriteStream is expected. Thanks Nicolas Cellier. http://code.google.com/p/pharo/issues/detail?id=5004

Nov. 20, 2011

Re: [Pharo-project] Zinc Post requests

by Sven Van Caekenberghe

On 20 Nov 2011, at 22:30, Lukas Renggli wrote: > Yes please, because the current Zinc does not work otherwise for POST requests. Name: Zinc-Seaside-SvenVanCaekenberghe.21 Author: SvenVanCaekenberghe Time: 20 November 2011, 10:55:28 pm UUID: 2d3dd79e-7210-4e42-ba85-b08e6f74b689 Ancestors: Zinc-Seaside-SvenVanCaekenberghe.20 added a new implementation of ZnZincServerAdaptor>>#requestBodyFor: this idea is that we have to return a String that contains the raw entity bytes. we don't do this when #requestFieldsFor: returns that data in an other form (i.e. when it is a POST with application/x-www-form-urlencoded or multipart/form-data). still this is inefficient for ZnStringEntity objects with a non-trivial encoding since they will be reencoded after just being decoded.

Nov. 20, 2011

Re: [Pharo-project] Zinc Post requests

by Lukas Renggli

On 20 November 2011 22:07, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > Well I guess this would then do the trick: > > requestBodyFor: aZincRequest > Â Â Â Â ^ String streamContents: [ :stream | > Â Â Â Â Â Â Â Â aZincRequest entity writeOn: (ZnBivalentWriteStream on: stream) ] > > but it hurts: at this point Zn has already parsed/interpreted the entity from bytes and the above code reencodes it again to bytes. That is why I asked if this is needed in all cases, I guess the body will not be used later on if it is either application/x-www-form-urlencoded or multipart/form-data (since these are handled in #requestFieldsFor:). If that is true, a faster fallback based on #contents should be possible (but with some ugly tests). Also a guard testing for entity #isEmpty and non-POST requests will probably be more efficient. > > Should I try to write a version and commit it ? Yes please, because the current Zinc does not work otherwise for POST requests. I understand the current behavior of Seaside is not ideal and it is cool that Zinc is more powerful than what Seaside expects, but then we have to find a way to expose that in compatible way. Lukas > > Sven > > On 20 Nov 2011, at 20:35, Lukas Renggli wrote: > >>> Given the current implementation: >>> >>> requestBodyFor: aZincRequest >>> Â Â Â ^ aZincRequest entity >>> >>> you get a ZnEntity subclass back, not a String which WARequest>>#setBody: seems to expect. >>> >>> As you certainly known, many different kinds of things could be uploaded in a POST, depending on the mime type, some of the important ones are in the subclasses of ZnEntity. I don't think a general conversion to String is possible, unless the idea is that that String should contain the byte representation of what got posted. >> >> Seaside expects a string containing the byte representation of what got posted. >> >>> The #contents method does try to return something useful (sometimes higher level Smalltalk objects). >>> >>> BTW, what is the difference between #requestBodyFor: and #requestFieldsFor: ? >> >> Have a look at the Kom adaptor: >> >> requestFieldsFor: aNativeRequest >> Â Â Â | fields | >> Â Â Â fields := WARequestFields new. >> Â Â Â aNativeRequest isPostRequest >> Â Â Â Â Â Â Â ifTrue: [ self postFieldsOf: aNativeRequest into: fields ]. >> Â Â Â ^ fields >> >> requestBodyFor: aNativeRequest >> Â Â Â ^ aNativeRequest rawRequestContents >> >> >> Lukas >> > > > -- Lukas Renggli www.lukas-renggli.ch

Nov. 20, 2011

Re: [Pharo-project] Decompiler writing to a ReadStream

by Nicolas Cellier

http://code.google.com/p/pharo/issues/detail?id=5004 2011/11/17 Martin McClure <martin(a)hand2mouse.com>: > I'm seeing the following in 1.3 and a 1.4 build from a couple of weeks ago: > > ============== > > ***System error handling failed*** > > [...] > > ReadStream(Object)>>shouldNotImplement > ReadStream>>nextPut: > EncoderForV3PlusClosures(Encoder)>>allLiterals > MethodNode>>generate: > MethodNode>>generate > MethodNode>>schematicTempNamesString > CompiledMethod>>decompileWithTemps > Decompiler>>decompileBlock: > > > =============== > > > Since the debugger can't open, I don't have much more information than > this. Looking at the decompiler, it's clear that it sometimes > initializes the Encoder's literalStream to a ReadStream, although that > stream is never read from, only written to. Changing the initialization > to a WriteStream just sends the system into infinite recursion. > > Any ideas on how to debug this? > > Thanks, > > -Martin > >

Nov. 20, 2011

Re: [Pharo-project] Zinc Post requests

by Sven Van Caekenberghe

Well I guess this would then do the trick: requestBodyFor: aZincRequest ^ String streamContents: [ :stream | aZincRequest entity writeOn: (ZnBivalentWriteStream on: stream) ] but it hurts: at this point Zn has already parsed/interpreted the entity from bytes and the above code reencodes it again to bytes. That is why I asked if this is needed in all cases, I guess the body will not be used later on if it is either application/x-www-form-urlencoded or multipart/form-data (since these are handled in #requestFieldsFor:). If that is true, a faster fallback based on #contents should be possible (but with some ugly tests). Also a guard testing for entity #isEmpty and non-POST requests will probably be more efficient. Should I try to write a version and commit it ? Sven On 20 Nov 2011, at 20:35, Lukas Renggli wrote: >> Given the current implementation: >> >> requestBodyFor: aZincRequest >> ^ aZincRequest entity >> >> you get a ZnEntity subclass back, not a String which WARequest>>#setBody: seems to expect. >> >> As you certainly known, many different kinds of things could be uploaded in a POST, depending on the mime type, some of the important ones are in the subclasses of ZnEntity. I don't think a general conversion to String is possible, unless the idea is that that String should contain the byte representation of what got posted. > > Seaside expects a string containing the byte representation of what got posted. > >> The #contents method does try to return something useful (sometimes higher level Smalltalk objects). >> >> BTW, what is the difference between #requestBodyFor: and #requestFieldsFor: ? > > Have a look at the Kom adaptor: > > requestFieldsFor: aNativeRequest > | fields | > fields := WARequestFields new. > aNativeRequest isPostRequest > ifTrue: [ self postFieldsOf: aNativeRequest into: fields ]. > ^ fields > > requestBodyFor: aNativeRequest > ^ aNativeRequest rawRequestContents > > > Lukas >

Nov. 20, 2011

Re: [Pharo-project] [Q] help with requesting a html page

by Edgar J. De Cleene

On 11/20/11 13:11 PM, "Max Leske" <maxleske(a)gmail.com> wrote: > What does your render code look like? Do you use a form to submit the data? Or > JavaScript? > > Max > > > On 20.11.2011, at 14:52, Edgar J. De Cleene wrote: > >> [Q] help with requesting a html page >> Friends: >> >> I have this code >> >> login >> | fields aPassword userName logged | >> fields := self request propertyAt: #postFields ifAbsent: []. >> fields ifNotNil:[ userName := (fields at: 'username'). >> aPassword := (fields at: 'password'). >> logged := HVNaughtieUsers new verifyPassword: aPassword forUser: userName >> ]. >> self halt. >> >> When I hit in the web browser , fields become nil. >> But if into Squeak I restart the method and do step by step, fields become >> populated with the right values. >> >> How I should do for the right values and avoid nil ? >> >> Thanks in advance >> >> Edgar > > I use HV2 so could mix html forms and external/internal JavaScript. > Very thanks for your attention > > Found the answer to my own question and is: > > login > | fields aPassword userName logged | > > fields := self request fields. > fields ifNotNil:[ userName := (fields at: 'username') first. > aPassword := (fields at: 'password') first. > logged := HVNaughtieUsers new verifyPassword: aPassword forUser: userName > ]. > self halt. > > > > Edgar > > PS- My goal is reverse engineering Mantis for a Squeak + Kom + HV2 + external > Javascript. > I called Sapis, see atached

Nov. 20, 2011

Re: [Pharo-project] #ifCurtailed:

by StÃ©phane Ducasse

[tx] ensure: [tx] On Nov 20, 2011, at 8:53 PM, Lukas Renggli wrote: > http://code.google.com/p/pharo/issues/detail?id=5003 > > On 20 November 2011 17:42, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> lukas can you open a bug entry? because we should fix this kind of problem. >> I will discuss it with igor. >> >> STef >> >> >> On Nov 20, 2011, at 3:52 PM, Lukas Renggli wrote: >> >>> They both behave the same way in that regard. The argument block is >>> always executed in the owning process, unless an outside process is >>> terminating the process. In this case it is the outside process that >>> unwinds the stack and evaluates the unwind blocks. A long standing bug >>> in my opinion. >>> >>> Lukas >>> >>> On 20 November 2011 15:19, Philippe Marschall <kustos(a)gmx.net> wrote: >>>> Hi >>>> >>>> Am I right that the argument to #ifCurtailed: is run in a different process >>>> (like #ensure: in an exception case)? >>>> >>>> Cheers >>>> Philippe >>>> >>>> >>>> >>> >>> >>> >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >>> >> >> >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch >

Nov. 20, 2011