- Pharo-users - lists.pharo.org

Unable to update Glamour-Core

by Offray Vladimir Luna CÃ¡rdenas

Hi, My image become unresponsive while making some debug, so I decided to start fresh and reinstall Grafoscopio, but I have some problems, with XML parser (so I disabled Soup temporarily) and with Glamour-Core, which provides and important part of the Grafoscopio experience. I tried also to install it from Monticello, without better results (to the version Glamour-Core-TudorGirba339). In both cases I get "SubscriptOutOfBounds: 17808" and this is the trace I get with the "Report" button (sorry I don't know other way to report): https://pastebin.com/wWM24w01 I will try with Pharo 7... The procedure is the same that was working just last week. I know the pains and advantages of having a dynamic system that is evolving quickly... hopefully a more stable platform will be there while the upcoming one is evolving. Cheers, Offray

Nov. 29, 2017

Re: [Pharo-users] I love the launcher!!!!

by Stephane Ducasse

Christophe I think that we should remove the blessed folder. Setf On Tue, Nov 28, 2017 at 5:36 PM, Christophe Demarey <christophe.demarey(a)inria.fr> wrote: > Hi Phil, > > Le 26 nov. 2017 Ã 22:25, phil(a)highoctane.be a Ã©crit : > > So, I try it on my CentOS 7 64 bit and... as there is no 64 bit version of > the launcherâ¦ > > > Right. > Canât you use the 32 bit version? > Anyway, I think it would be good to have a 64 bit version. Could you open > an issue for that please? > > > pharo6-64-ui PharoLauncher.image > This interpreter (vers. 68021) cannot read image file (vers. 6521). > Press CR to quit... > > How is one using the launcher for 64 bit stuff? > > Phil > > On Sun, Nov 26, 2017 at 9:45 PM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: >> >> If you don't try you will not understand what you miss. >> >> On Sun, Nov 26, 2017 at 2:10 PM, Herby VojÄÃk <herby(a)mailbox.sk> wrote: >> > Stephane Ducasse wrote: >> >> >> >> Then do not try :) like that you will never get a chance to know :) >> > >> > >> > Could you please explain? I understood your sentence has high dose of >> > homour >> > which I cannot decipher since I lack certain abilities for that. >> > >> > Thanks, Herby >> > >> >> Stef >> >> >> >> >> >> On Sun, Nov 26, 2017 at 1:48 PM, Herby VojÄÃk<herby(a)mailbox.sk> wrote: >> >>> >> >>> Stephane Ducasse wrote: >> >>>> >> >>>> Why don't you try? It does not bite. >> >>>> >> >>>> For me it works in all scenario. I have projects that i manage over >> >>>> several weeks and others I drop day to day. >> >>>> And I have also startup script per versions. >> >>> >> >>> >> >>> Maybe I will. The main problem was I didn't what it's good about at >> >>> all - >> >>> load image for a version, runs it - what's the "wow it's great" about? >> >>> Missed part was it loads correct vm; plus makes sense when you have >> >>> hundreds >> >>> (I don't). Now it must be combined with the startup script magic to >> >>> work >> >>> with long-time projects, but those are also new to me - did not know >> >>> of >> >>> them >> >>> until your booklet, not using them at all yet. >> >>> >> >>> Herby >> >>> >> >>> >> >>>> Stef >> >>>> >> >>>> On Fri, Nov 24, 2017 at 3:10 PM, Herby VojÄÃk<herby(a)mailbox.sk> >> >>>> wrote: >> >>>>> >> >>>>> Thank you all, now I understand it better. Good for lots of >> >>>>> "branches". >> >>>>> >> >>>>> However, I wonder how does it work with the rule I read somewhere: >> >>>>> "start >> >>>>> each day [of work on a project] with a new image", which means I >> >>>>> should >> >>>>> not >> >>>>> reuse clean new image (as it needs populating from VCSes etc.) nor >> >>>>> reuse >> >>>>> existing image (I should start with the new one). Or does it combine >> >>>>> with >> >>>>> some startup-magic described in one of the recent Steph's booklets, >> >>>>> the >> >>>>> "one >> >>>>> start per [new] image" case (but again, one should discriminate >> >>>>> projects >> >>>>> from each other)? >> >>>>> >> >>>>> Thanks, Herby >> >>>>> >> >>>>> Peter UhnÃ¡k wrote: >> >>>>>> >> >>>>>> Hi Herby, >> >>>>>> >> >>>>>> normally people use different images for their different projects, >> >>>>>> different versions, trying things, etc. Which means we end up with >> >>>>>> many >> >>>>>> locations on disk, and it can be hard to track. >> >>>>>> So PharoLauncher is a nice tool where you can download fresh image >> >>>>>> just >> >>>>>> by clicking, and you see the list of your local images and can >> >>>>>> launch >> >>>>>> them, etc. >> >>>>>> >> >>>>>> Peter >> >>>>>> >> >>>>>> On Thu, Nov 23, 2017 at 12:56 PM, Herby VojÄÃk<herby(a)mailbox.sk >> >>>>>> <mailto:herby@mailbox.sk>> wrote: >> >>>>>> >> >>>>>> Stephane Ducasse wrote: >> >>>>>> >> >>>>>> Hi >> >>>>>> >> >>>>>> I love the PharoLauncher. >> >>>>>> >> >>>>>> >> >>>>>> Pardon my question, I have downloaded it and looked at it, >> >>>>>> but I >> >>>>>> don't get it. What does it do / what are the use cases >> >>>>>> (honest >> >>>>>> question)? >> >>>>>> >> >>>>>> Thanks, Herby >> >>>>>> >> >>>>>> >> >>>>>> It helps me to manage my parallel development and >> >>>>>> projects. >> >>>>>> >> >>>>>> We should put a link on the Pharo web site because >> >>>>>> >> >>>>>> http://files.pharo.org/platform/launcher/ >> >>>>>> <http://files.pharo.org/platform/launcher/> >> >>>>>> >> >>>>>> is arcane. >> >>>>>> >> >>>>>> Stef >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>> >> >> >> > >> > >> >> > >

Nov. 28, 2017

Re: [Pharo-users] PetitCompiler loading problem

by Julien

Hello, Sorry for the late answer. I use the following script: Gofer new smalltalkhubUser: 'JanKurs' project: 'PetitParser'; configurationOf: #PetitCompiler; load. (Smalltalk at: #ConfigurationOfPetitCompiler) perform: #'loadDevelopmentâ. Julien --- Julien Delplanque http://juliendelplanque.be/phd.html Doctorant Ã lâUniversitÃ© de Lille 1 Equipe Rmod, Inria NumÃ©ro de tÃ©lÃ©phone: +333 59 35 86 40 > Le 24 nov. 2017 Ã 09:57, Tudor Girba <tudor(a)tudorgirba.com> a Ã©crit : > > Hi, > > What script are you using? > > Cheers, > Doru > > >> On Nov 24, 2017, at 9:42 AM, Julien <julien.delplanque(a)inria.fr> wrote: >> >> Hi, >> >> Thanks for you answer. >> >> I already tried and I do encounter the same issue with #development version. >> >> Julien >>> Le 24 nov. 2017 Ã 09:40, Tudor Girba <tudor(a)tudorgirba.com> a Ã©crit : >>> >>> Hi, >>> >>> PetitCompiler is not released for 6.1. Please try with #development and let me know if you still encounter the issue. >>> >>> Cheers, >>> Doru >>> >>> >>>> On Nov 24, 2017, at 8:55 AM, Julien <julien.delplanque(a)inria.fr> wrote: >>>> >>>> Hello, >>>> >>>> Iâd like to try PetitCompiler to speed-up a parser I did. >>>> >>>> When trying to load it in a Pharo 6.1 image I have an error related to its configuration: >>>> >>>> Gofer new smalltalkhubUser: 'JanKurs' project: 'PetitParser'; >>>> configurationOf: #PetitCompiler; load. >>>> (Smalltalk at: #ConfigurationOfPetitCompiler) perform: #'loadStable'. >>>> >>>> Â« Error : Name not found : Magritte-Tests-Pharo-Model Â» >>>> >>>> Can someone help me? >>>> >>>> I haven't tried in older images. >>>> >>>> Julien >>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "No matter how many recipes we know, we still value a chef." >>> >>> >>> >>> >>> >>> >>> >>> >> >> > > -- > www.tudorgirba.com > www.feenk.com > > "Don't give to get. Just give." > > > > > > >

Nov. 28, 2017

Strange behaviour when commit+push with Iceberg

by Julien

Hello, Sometimes, when I do Â« commit and push Â» with Iceberg, I got this strange behaviour (see1st screenshot). I **must** interrupt the process to stop this madness. Then, I get even weirder things related to morphic (see the other screenshot). Then my image come back to a normal state and the commit + push have been performed. I hope this feedback can be helpful. I understand it may be too abstract description to fix the problem but I can not provide a formal way to reproduce this bug. Nevertheless, I thought I should report this behaviour which is not normal. Except this, I use Iceberg everyday for my projects now and yet it works well for me (I guess I have the right workflow that avoid problems). --- Julien Delplanque http://juliendelplanque.be/phd.html Doctorant Ã lâUniversitÃ© de Lille 1 Equipe Rmod, Inria NumÃ©ro de tÃ©lÃ©phone: +333 59 35 86 40

Nov. 28, 2017

Re: [Pharo-users] Autoupdate of playground contents up to the last keystroke

by Offray Vladimir Luna CÃ¡rdenas

Thanks Doru. Works like a charm. Cheers, Offray On 28/11/17 01:37, Tudor Girba wrote: > Hi, > > You are reading the wrong port. > > Try this instead: > > playground := GTPlayground new. > playground openOn: GTPlayPage new. > playground > onChangeOfPort: #text > act: [ :x | self inform: (x pane port: #text) value ] > > Cheers, > Doru > > > >> On Nov 28, 2017, at 12:48 AM, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: >> >> Hi, >> >> Grafoscopio uses Doru's suggestion for auto-updating its contents, as published in http://ws.stfx.eu/ETEC2JH7363M, but if you test that code you will see that the contents showed in the inform message are one keystroke behind of the current playground content, as showed below, which creates usability issues (we need to add empty spaces and new lines to get the proper content of the Playground saved). >> >> <cielpnbindpgogab.png> >> >> There is any way to store/show the actual contents of the playground, instead of one keystroke behind. >> >> Thanks, >> >> Offray > -- > www.tudorgirba.com > www.feenk.com > > "We are all great at making mistakes." > > > > > > > > > >

Nov. 28, 2017

Re: [Pharo-users] reusing ZnClient session

by Peter UhnÃ¡k

Hi Sven, yes `session:` would be the ideal solution. But because it wasn't there (only getter) I wasn't sure whether this was a design decision - e.g. because sessions can't be reused. Thanks! Peter On Tue, Nov 28, 2017 at 10:51 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Peter, > > > On 28 Nov 2017, at 10:42, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > > Hi, > > > > I have a scenario where I need to login to some web app and then reuse > the session/cookies in further requests. > > > > The basic approach (as presented in Enterprise Pharo book) works just > fine > > > > client := ZnClient new. > > > > client > > url: 'http://example.com/login'; > > formAt: 'username' put: 'john.doe(a)acme.com'; > > formAt: 'password' put: 'trustno1'; > > post. > > > > client > > get: 'http://example.com/my-file'. > > > > The problem is when I want to change the way response is retrieved. E.g. > > > > client > > accept: 'text/json'; > > contentReader: [ :entity | STON fromString: entity contents ]; > > get: 'http://example.com/some.json'. > > > > "uh-oh... it still uses STON contentReader" > > client > > get: 'http://example.com/homepage.html' > > > > > > Of course I could manually copy all the cookies, however I imagine there > is a better approach. Maybe injecting session from one ZnClient instance to > another? > > > > Thanks, > > Peter > > Reusing a ZnClient makes most sense when you access one host in a uniform > way. > > Like you say, there are different options > > - reset the content reader when needed (assign nil) > - make your content reader more intelligent (check the entity's content > type and act accordingly) > - get the #session from one client and use in on another one (#session: > must be added for this) > > ZnClient holds all kind of state (it is also a builder), so some > occasional resetting (or managing this state) can be needed. > > Does this help ? > > Sven > > >

Nov. 28, 2017

Re: [Pharo-users] files.pharo.org downloads => needs testers

by Peter UhnÃ¡k

What is the relationship between this and http://mirror.pharo.org? Considering you are already working around these servers, would it be possible to add HTTPS? On Tue, Nov 28, 2017 at 5:43 PM, Christophe Demarey < christophe.demarey(a)inria.fr> wrote: > Hi all, > > We set up 2 new servers to replace (at least for some time) the > problematic files.pharo.org server (slow downloads, bad CRC). > Please, could you test these new servers and give us feedback to see if > downloads are fast and nom ore CRC errors? > * http://file-pharo.inria.fr/ > * http://files2.pharo.org (hosted on the cloud) > > Data might be a bit outdated (sync last friday) but is just for testing > now. > > According to your feedbacks, we will switch official URLs to one of these > servers. > The situation should be back to normal soon. > > Christophe >

Nov. 28, 2017

files.pharo.org downloads => needs testers

by Christophe Demarey

Hi all, We set up 2 new servers to replace (at least for some time) the problematic files.pharo.org <http://files.pharo.org/> server (slow downloads, bad CRC). Please, could you test these new servers and give us feedback to see if downloads are fast and nom ore CRC errors? * http://file-pharo.inria.fr/ * http://files2.pharo.org (hosted on the cloud) Data might be a bit outdated (sync last friday) but is just for testing now. According to your feedbacks, we will switch official URLs to one of these servers. The situation should be back to normal soon. Christophe

Nov. 28, 2017

Re: [Pharo-users] I love the launcher!!!!

by Christophe Demarey

Hi Phil, > Le 26 nov. 2017 Ã 22:25, phil(a)highoctane.be a Ã©crit : > > So, I try it on my CentOS 7 64 bit and... as there is no 64 bit version of the launcherâ¦ Right. Canât you use the 32 bit version? Anyway, I think it would be good to have a 64 bit version. Could you open an issue for that please? > > pharo6-64-ui PharoLauncher.image > This interpreter (vers. 68021) cannot read image file (vers. 6521). > Press CR to quit... > > How is one using the launcher for 64 bit stuff? > > Phil > > On Sun, Nov 26, 2017 at 9:45 PM, Stephane Ducasse <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com>> wrote: > If you don't try you will not understand what you miss. > > On Sun, Nov 26, 2017 at 2:10 PM, Herby VojÄÃk <herby(a)mailbox.sk <mailto:herby@mailbox.sk>> wrote: > > Stephane Ducasse wrote: > >> > >> Then do not try :) like that you will never get a chance to know :) > > > > > > Could you please explain? I understood your sentence has high dose of homour > > which I cannot decipher since I lack certain abilities for that. > > > > Thanks, Herby > > > >> Stef > >> > >> > >> On Sun, Nov 26, 2017 at 1:48 PM, Herby VojÄÃk<herby(a)mailbox.sk <mailto:herby@mailbox.sk>> wrote: > >>> > >>> Stephane Ducasse wrote: > >>>> > >>>> Why don't you try? It does not bite. > >>>> > >>>> For me it works in all scenario. I have projects that i manage over > >>>> several weeks and others I drop day to day. > >>>> And I have also startup script per versions. > >>> > >>> > >>> Maybe I will. The main problem was I didn't what it's good about at all - > >>> load image for a version, runs it - what's the "wow it's great" about? > >>> Missed part was it loads correct vm; plus makes sense when you have > >>> hundreds > >>> (I don't). Now it must be combined with the startup script magic to work > >>> with long-time projects, but those are also new to me - did not know of > >>> them > >>> until your booklet, not using them at all yet. > >>> > >>> Herby > >>> > >>> > >>>> Stef > >>>> > >>>> On Fri, Nov 24, 2017 at 3:10 PM, Herby VojÄÃk<herby(a)mailbox.sk <mailto:herby@mailbox.sk>> wrote: > >>>>> > >>>>> Thank you all, now I understand it better. Good for lots of "branches". > >>>>> > >>>>> However, I wonder how does it work with the rule I read somewhere: > >>>>> "start > >>>>> each day [of work on a project] with a new image", which means I should > >>>>> not > >>>>> reuse clean new image (as it needs populating from VCSes etc.) nor > >>>>> reuse > >>>>> existing image (I should start with the new one). Or does it combine > >>>>> with > >>>>> some startup-magic described in one of the recent Steph's booklets, the > >>>>> "one > >>>>> start per [new] image" case (but again, one should discriminate > >>>>> projects > >>>>> from each other)? > >>>>> > >>>>> Thanks, Herby > >>>>> > >>>>> Peter UhnÃ¡k wrote: > >>>>>> > >>>>>> Hi Herby, > >>>>>> > >>>>>> normally people use different images for their different projects, > >>>>>> different versions, trying things, etc. Which means we end up with > >>>>>> many > >>>>>> locations on disk, and it can be hard to track. > >>>>>> So PharoLauncher is a nice tool where you can download fresh image > >>>>>> just > >>>>>> by clicking, and you see the list of your local images and can launch > >>>>>> them, etc. > >>>>>> > >>>>>> Peter > >>>>>> > >>>>>> On Thu, Nov 23, 2017 at 12:56 PM, Herby VojÄÃk<herby(a)mailbox.sk <mailto:herby@mailbox.sk> > >>>>>> <mailto:herby@mailbox.sk <mailto:herby@mailbox.sk>>> wrote: > >>>>>> > >>>>>> Stephane Ducasse wrote: > >>>>>> > >>>>>> Hi > >>>>>> > >>>>>> I love the PharoLauncher. > >>>>>> > >>>>>> > >>>>>> Pardon my question, I have downloaded it and looked at it, but I > >>>>>> don't get it. What does it do / what are the use cases (honest > >>>>>> question)? > >>>>>> > >>>>>> Thanks, Herby > >>>>>> > >>>>>> > >>>>>> It helps me to manage my parallel development and projects. > >>>>>> > >>>>>> We should put a link on the Pharo web site because > >>>>>> > >>>>>> http://files.pharo.org/platform/launcher/ <http://files.pharo.org/platform/launcher/> > >>>>>> <http://files.pharo.org/platform/launcher/ <http://files.pharo.org/platform/launcher/>> > >>>>>> > >>>>>> is arcane. > >>>>>> > >>>>>> Stef > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>> > >> > > > > > > >

Nov. 28, 2017

Re: [Pharo-users] Fuel transfer from Pharo 1.4 to Pharo 6.1

by Mariano Martinez Peck

On Tue, Nov 28, 2017 at 10:20 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > On 28 Nov 2017, at 13:52, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > > > > > > > On Tue, Nov 28, 2017 at 9:31 AM, Andreas Brodbeck <dassi(a)mindclue.ch> > wrote: > > Am 28.11.17 um 12:46 schrieb Mariano Martinez Peck: > > > Hi Andreas, > > > > > > Do you know why method contexts are trying to be serialized? Of course, > > > probably because of closures. Do you think / know / are aware of > closures > > > as part of your graph? Maybe Sorted Collection? > > > I am asking because if the only thing is SortedCollection then we can > use > > > some hook... > > > > I have closures in several places in the object graph. These are objects > > with some pluggable functionality, which I rely on. > > > > > > OK. The question is then if those closures are "clean" or not. In other > words, what's their scope? Do they refer to variables defined outside the > closure (in which case you would need the methods contexts / stack) or are > they clean in the sense that you could be able to replace them via a string > and then compile them again ? > > Some time ago we added a #isClean to BlockClosure. You can test a few of > your closures to see if this is the case or not. > > > > Btw, I have an application for a client in which we also have closures > to define some pluggable behavior. But what I do is: > > > > 1) guarantee they are 100% clean (does not go outside of scope) > > 2) aside from the "block" instVar I also add another instVar which is > the "string" version of it. Then I always implement # > fuelIgnoredInstanceVariableNames to ignore all those "block" instVars, > yet DO NOT ignore the "string" like of those closures. Then, of course, the > getter of the block instvar does a lazy compilation if the block instVar is > nil... > > Ah, that's cheating ;-) > I didn't say it wasn't hahahahahaha > > But totally acceptable with clean blocks. > > So, > > [ :x :y | x < y ] isClean. > > => true > > [ :x :y | x < y ] sourceNode formattedCode. > > => '[ :x :y | x < y ]' > > But > > Compiler evaluate: '[ :x :y | x < y ]'. > > => [ :arg1 :arg2 | arg1 < arg2 ] > > So the argument names get lost, which seems like a pity. How are you doing > it ? Can it be done differently ? > > I really don't care at all how closures look like. The idea is: always keep the string version instVars and sixx/fuel ignore the block version. block version getter compiles from string if nil. I think you might have understood I use the same instVar and that sometimes I set a string and sometimes I set a closure. If that's the case, then yes, I ended up with 2 different instVars... Example: FaAction class >> fuelIgnoredInstanceVariableNames ^ #('actionBlock') FaPersistentObject subclass: #FaAction instanceVariableNames: 'action actionBlock' classVariableNames: '' package: 'FA-Core' FaAction >> actionBlock ^ actionBlock ifNil: [ action isEmptyOrNil ifTrue: [ nil ] ifFalse: [actionBlock := self compile: action ] ] That's is obviously a simplified example and it might have some syntax error but I guess you get the idea, right? So this has worked very well for me with Fuel on Pharo and Sixx on GemStone. There are obvious drawbacks like: it only works for clean closures, having to have 2 instVar per "concept" , have to compile when I only have the string, etc etc. > > I know you already have your application written, but I am trying to > explain how I was able to use Fuel for this case... > > > > > > Just for my better understanding, I like to ask: The FLMethodChanged > > errors will show up for *EVERY* method of a materialized object (Since > > the bytecodesHash changed for every method) or just those methods which > > involve fuel-persisted MethodContexts? (Sorry, if the question is > > stupid, but I am rather new to Fuel internals) > > > > > > As far as I can remember, the latter. > > > > > > > > > > Cheers, > > Andreas > > > > -- > > Andreas Brodbeck > > www.mindclue.ch > > > > > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > -- Mariano http://marianopeck.wordpress.com

Nov. 28, 2017