September 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] image persistency does not seem to work

by Tudor Girba

Hi Marcus, hi Lucas, Thanks. I removed the call and everything is Ok. Cheers, Doru On 24 Sep 2011, at 18:55, Lukas Renggli wrote: > You can probably remove the call to #saveImageSegments. And the Image Segment persistency strategy should probably be removed too. > > Lukas > > On Saturday, 24 September 2011, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > > > I am testing the latest Pier2 based on Pharo 1.3, and I got an error when trying to use the image-based persistency. > > > > The error happens in: > > > > PRImagePersistency>>saveImageAndBackupAs: aString > > ... > > image openSourceFiles; saveImageSegments; snapshot: true andQuit: false > > > > in particular, the SmalltalkImage does not understand saveImageSegments anymore. Is this some cleanup that happened in Pharo and that requires a new package to be loaded? > > > > Cheers, > > Doru > > > > > > -- > > www.tudorgirba.com > > > > "To utilize feedback, you first have to acquire it." > > > > > > > > -- > Lukas Renggli > www.lukas-renggli.ch -- www.tudorgirba.com "To utilize feedback, you first have to acquire it."

Sept. 24, 2011

Re: [Pharo-project] image persistency does not seem to work

by Marcus Denker

On Sep 24, 2011, at 6:50 PM, Tudor Girba wrote: > Hi, > > I am testing the latest Pier2 based on Pharo 1.3, and I got an error when trying to use the image-based persistency. > > The error happens in: > > PRImagePersistency>>saveImageAndBackupAs: aString > ... > image openSourceFiles; saveImageSegments; snapshot: true andQuit: false > > in particular, the SmalltalkImage does not understand saveImageSegments anymore. Is this some cleanup that happened in Pharo and that requires a new package to be loaded? > We started to clean up ImageSegments in 1.3. Most of ImageSegments is there (and even cleaned and fixed by Mariano while he analyzed the code). We removed all of ImageSegment code in the image in 1.4, though. After *very* careful analysis *and* implementing a better replacement... (Fuel). The #saveImageSegments when saving the Image itself I removed in 1.3 already (after sending a mail to the list to ask if anyone uses it). The idea was that on image save, if image segments are written to disk, it would copy them over if you rename the image on save: saveImageSegments: previousFullImageName "This method is used for example when you save an image with another name. In this case, if there are segments written to files and there are ImageSegment instances, then it copies the file from the previous image location, to the new one. It is like a backup of the segment files when renaming an image. " | haveSegs oldImageSegDir theClass newImageSegDir | "If the class does not exist or has no instances, it has no sense to backUp the segments." self areThereImageSegments ifFalse: [ ^ self ]. theClass := Smalltalk globals at: #ImageSegment. oldImageSegDir := theClass segmentDirectoryFrom: previousFullImageName. newImageSegDir := theClass segmentDirectory. "create the folder" oldImageSegDir fileNames do: [ :theName | | imageSegmentName "copy all segment files" | imageSegmentName := oldImageSegDir pathName , FileDirectory slash , theName. newImageSegDir copyFileWithoutOverwriteConfirmationNamed: imageSegmentName toFileNamed: theName ] So if your image has no image segments, than it's ok to just remove the call. Marcus -- Marcus Denker -- http://marcusdenker.de

Sept. 24, 2011

Re: [Pharo-project] image persistency does not seem to work

by Lukas Renggli

You can probably remove the call to #saveImageSegments. And the Image Segment persistency strategy should probably be removed too. Lukas On Saturday, 24 September 2011, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I am testing the latest Pier2 based on Pharo 1.3, and I got an error when trying to use the image-based persistency. > > The error happens in: > > PRImagePersistency>>saveImageAndBackupAs: aString > ... > image openSourceFiles; saveImageSegments; snapshot: true andQuit: false > > in particular, the SmalltalkImage does not understand saveImageSegments anymore. Is this some cleanup that happened in Pharo and that requires a new package to be loaded? > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "To utilize feedback, you first have to acquire it." > > > -- Lukas Renggli www.lukas-renggli.ch

Sept. 24, 2011

[Pharo-project] image persistency does not seem to work

by Tudor Girba

Hi, I am testing the latest Pier2 based on Pharo 1.3, and I got an error when trying to use the image-based persistency. The error happens in: PRImagePersistency>>saveImageAndBackupAs: aString ... image openSourceFiles; saveImageSegments; snapshot: true andQuit: false in particular, the SmalltalkImage does not understand saveImageSegments anymore. Is this some cleanup that happened in Pharo and that requires a new package to be loaded? Cheers, Doru -- www.tudorgirba.com "To utilize feedback, you first have to acquire it."

Sept. 24, 2011

Re: [Pharo-project] new Cog VMs available...

by StÃ©phane Ducasse

Thanks eliot. Do you have tests that we could harvest to create a non regession database? Stef > ...in http://www.mirandabanda.org/files/Cog/VM/VM.r2495/. These fix the regression introduced in r2487 in > introducing faster MNu processing. The bug was the leaking up of an error code that was misinterpreted as > a valid target machine code method. Thanks /very/ much to those of you who tested the 2493 & 2494 VMs. > With your help this bug was found quickly. I now have reason to hope that these VMs will be quite stable. > > > Here's the readme: > CogVM binaries as per VMMaker.oscog-eem.127/r2495. Fix MNU PIC creation not > to answer an error code to the interpreter. This is the call 0x00000013 bug. > > again thanks > -- > best, > Eliot >

Sept. 24, 2011

[Pharo-project] new Cog VMs available...

by Eliot Miranda

...in http://www.mirandabanda.org/files/Cog/VM/VM.r2495/. These fix the regression introduced in r2487 in introducing faster MNu processing. The bug was the leaking up of an error code that was misinterpreted as a valid target machine code method. Thanks /very/ much to those of you who tested the 2493 & 2494 VMs. With your help this bug was found quickly. I now have reason to hope that these VMs will be quite stable. Here's the readme: CogVM binaries as per VMMaker.oscog-eem.127/r2495. Fix MNU PIC creation not to answer an error code to the interpreter. This is the call 0x00000013 bug. again thanks -- best, Eliot

Sept. 23, 2011

Re: [Pharo-project] response to an AJAX POST request

by Richard Durr

Likely the problem, see: http://meteatamel.wordpress.com/2011/02/11/access-control-allow-origin/ and from there on: https://developer.mozilla.org/En/HTTP_Access_Control On Fri, Sep 23, 2011 at 11:40 PM, Richard Durr <richard.durr(a)googlemail.com>wrote: > Maybe the Access-Control-Allow-Origin blocks because of the different > ports? > > On Fri, Sep 23, 2011 at 5:56 PM, Bernat Romagosa < > tibabenfortlapalanca(a)gmail.com> wrote: > >> Ok, so I've just learnt I should be doing: >> >> answerTo: aRequest >> | response | >> aRequest postDataKeys do: [:eachKey | Transcript show: (aRequest >> postDataAt: eachKey) value]. >> response := HTTPResponse ok. >> ^response >> >> But then the client's javascript console shows: "XMLHttpRequest cannot >> load http://localhost:4001/amber/. Origin http://localhost:4000<http://localhost/>is not allowed by Access-Control-Allow-Origin. >> " >> >> Ideas? >> >> 2011/9/23 Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> >> >>> Hi lists, >>> >>> I'm trying to get Amber and Pharo to talk to each other by using Ajax. So >>> far, using an Ajax wrapper that Laurent wrote, I managed to get Pharo to >>> receive a message from Amber by doing: >>> >>> |ajax| >>> ajax := (Ajax url: 'http://localhost:4001/amber/'). >>> ajax options >>> at: 'type' put: 'POST'; >>> at: 'data' put: 'Hi Pharo!'; >>> at: 'timeout' put: 500. >>> ajax onSuccessDo: [console log: 'ok!']; >>> onErrorDo: [console log: 'not so ok...']. >>> ajax send >>> >>> This is captured by a Swazoo resource, that does the following: >>> >>> answerTo: aRequest >>> | response | >>> [aRequest postData stream anyDataReady] >>> whileTrue: >>> [Transcript show: aRequest postData stream next]. >>> >>> response := HTTPResponse ok. >>> response >>> contentType: 'text/plain'; >>> entity: 'Done!'. >>> ^response >>> >>> My intention here is just to read the message data and return an OK >>> response, but for some reason stream anyDataReady keeps evaluating to true >>> even when there's no more data to read, so the code underneath is never >>> executed. The Transcript shows 'Hi Pharo!' though, so I'm sure the request >>> is being received and read. >>> >>> Any light shed on this would be of great help... >>> >>> Thanks! >>> >>> -- >>> Bernat Romagosa. >>> >> >> >> >> -- >> Bernat Romagosa. >> > >

Sept. 23, 2011

Re: [Pharo-project] response to an AJAX POST request

by Richard Durr

Maybe the Access-Control-Allow-Origin blocks because of the different ports? On Fri, Sep 23, 2011 at 5:56 PM, Bernat Romagosa < tibabenfortlapalanca(a)gmail.com> wrote: > Ok, so I've just learnt I should be doing: > > answerTo: aRequest > | response | > aRequest postDataKeys do: [:eachKey | Transcript show: (aRequest > postDataAt: eachKey) value]. > response := HTTPResponse ok. > ^response > > But then the client's javascript console shows: "XMLHttpRequest cannot > load http://localhost:4001/amber/. Origin http://localhost:4000<http://localhost/>is not allowed by Access-Control-Allow-Origin. > " > > Ideas? > > 2011/9/23 Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> > >> Hi lists, >> >> I'm trying to get Amber and Pharo to talk to each other by using Ajax. So >> far, using an Ajax wrapper that Laurent wrote, I managed to get Pharo to >> receive a message from Amber by doing: >> >> |ajax| >> ajax := (Ajax url: 'http://localhost:4001/amber/'). >> ajax options >> at: 'type' put: 'POST'; >> at: 'data' put: 'Hi Pharo!'; >> at: 'timeout' put: 500. >> ajax onSuccessDo: [console log: 'ok!']; >> onErrorDo: [console log: 'not so ok...']. >> ajax send >> >> This is captured by a Swazoo resource, that does the following: >> >> answerTo: aRequest >> | response | >> [aRequest postData stream anyDataReady] >> whileTrue: >> [Transcript show: aRequest postData stream next]. >> >> response := HTTPResponse ok. >> response >> contentType: 'text/plain'; >> entity: 'Done!'. >> ^response >> >> My intention here is just to read the message data and return an OK >> response, but for some reason stream anyDataReady keeps evaluating to true >> even when there's no more data to read, so the code underneath is never >> executed. The Transcript shows 'Hi Pharo!' though, so I'm sure the request >> is being received and read. >> >> Any light shed on this would be of great help... >> >> Thanks! >> >> -- >> Bernat Romagosa. >> > > > > -- > Bernat Romagosa. >

Sept. 23, 2011

Re: [Pharo-project] jenkis is down

by Mariano Martinez Peck

sorry, I didn't see it report it. thanks marcus On Fri, Sep 23, 2011 at 9:01 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > Yes, known problem and reported since yesterday... > > > On Sep 23, 2011, at 7:31 PM, Mariano Martinez Peck wrote: > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > -- > Marcus Denker -- http://marcusdenker.de > > > -- Mariano http://marianopeck.wordpress.com

Sept. 23, 2011

Re: [Pharo-project] looking for boring morphs

by Edgar J. De Cleene

On 9/23/11 9:47 AM, "Esteban Lorenzano" <estebanlm(a)gmail.com> wrote: > Hi, > I have a customer who are asking me for a very small app... but a desktop app, > not the usual web app I'm more used to do... > and of course, I'm doing it with pharo! > So far... this is working really well... much easier as I supposed it would be > :) > I'm using glamour, magritte, keybindings, hpdf, mongodb... and small tweaks by > my self to make it work as expected, but not so much. > > (btw... I want to say that a couple of years ago, this wont be an option at > all... this is due to the great effort the pharo community is doing, and I'm > really proud of it. Thank you guys!) > > well... now... I need some morphs a regular management application usually > needs: > > 1) NumberInputFieldMorph (A child of TextMorph or PluggableTextMorph who > allows different kind of numbers -> this is easy to do, but better if it is > already somewhere) http://wiki.squeak.org/squeak/5906 "How to do a Calculator using pure Morphic" Hope this help > 2) DateInputFieldMorph (a morph with a "date picker" -> this is harder, > because I have very limited knowledge about morphic) > 3) I'm sure there are others I didn't needed yet, but there are needed in this > kind of applications > > so... does someone has this kind of morphs somewhere? I would really > appreciate it, because you know... it is doable, but time is tyrant and better > if I can reuse someones work ;) > > cheers, > Esteban And see https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/ designer Sure some ideas was useful. Edgar

Sept. 23, 2011