- Pharo-users - lists.pharo.org

Issue on Seaside beginning

by Cheikhou Oumar KA

Hello. I am following #PharoMOOC and it become more and more exciting. I were doing TinyBlog exercise and I got an issue. I looked at the forum but any solution and I am stuck now like many others. I have created my class TBApplicationRootComponent, create a server that listen at :8080 and start it, regiser my application.... But at http://localhost:8080/browse I got this Image in my browser [image: Images intÃ©grÃ©es 1] Any help is welcome. Thanks -- *Cheikhou Oumar KA * å¥¥ é©¬ å° Â·è°¢ èµ« Â·å Doctorant Informatique cheikhouka(a)gmail.com

June 4, 2016

the impact of moldability

by Tudor Girba

Hi, There were a couple of emails in the recent period that questioned the usefulness of moldability (the ability of developers to customize their tools deeply and inexpensively). More specifically, the question was about the moldability of the GTDebugger. I put together a couple of thoughts of why we think that moldability is actually a competitive advantage: http://www.humane-assessment.com/blog/the-impact-of-moldability/ Please read it and provide feedback. Cheers, Doru -- www.tudorgirba.com www.feenk.com "Reasonable is what we are accustomed with."

June 4, 2016

Re: [Pharo-users] One comment to new Pharo5 debugger

by Gabriel Cotelli

Hi, I undestand and really liked the idea of a moldable debugger and it's true that the button actions act over the stack, however the decision on what action to use is taken not looking to the stack pane (normally I've decided what to do looking on the source pane). In this context, the buttons are far away where the attention usually is (the code pane). IMHO for the user experience point of view I think is better to have the actions below the stack list and above the stack pane to let the user do not diverge his attention. I'm proposing not dettaching the action buttons for the stack pane, just changing the location (and also moving and inverting the direction of the tab label to not waste space). Maybe something like this (sorry no photoshop here :) ): â We need to figure it out a way to improve this situation. Regards, Gabriel On Sat, Jun 4, 2016 at 3:45 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Sabine (and others that asked this question), > > Thanks for the feedback. Sorry for the delayed reply, but I am traveling > these days and I have limited online time. Also, this email took some time > to write (I started it about a week ago). > > I will answer the buttons issue. The reason they are in a different place > than where they used to be is related to new constraints that come with the > new debugger. While the default interface looks like a regular debugger, > the main feature of the GTDebugger is that it can be customized to match a > specific domain or library. > > Let me provide an example of a scenario of debugging PetitParser: > > PPArithmeticParser parse: '1+2*3^(34-2)â > > The default debugger looks like this: > > > But, because we have PetitParser code on the stack, we can switch to a > custom debugger: > > > This one also features the input stream next to the code. Also, note that > the stack received 3 new button actions. But, this is not all. Next to the > source, there are other tabs, and we can switch to one of those: > > > This one shows the source as well, but in a graphical form. > > So, if we step back and talk about the buttons, you will see that if we > would have put the buttons on the source tabs, you have had no way to > advance in this state. We could have also duplicated behavior and put the > buttons on the new presentation as well, but the space is much smaller and > since we now have large buttons instead of only icons we needed to deal > with that as well. We encountered similar situations in other debuggers > (not all, though). > > But, from a more point of view, the actions act on the stack. So, if we > take an object-oriented approach for designing the UI, it makes sense to > place those actions next to the context they act on. All these reasons made > us choose to put them next to the stack and not next to the source. > > We certainly understand that this is a departure from the classic debugger > and perhaps this is not the best way of doing things, but that was the > rationale we went through. I would be happy to hear other suggestions, but > please understand that we need to take into account the full spectrum of > constraints when choosing solutions. > > In any case, the idea of this debugger is that you can change it in the > way you want and customize it specifically for your needs. We still need to > document how to do that, but if someone wants to start creating a custom > debugger we could use the experience to drive the documentation. > > Does this explain the situation? > > Cheers, > Doru > > > On May 25, 2016, at 9:43 PM, Sabine Manaa <manaa.sabine(a)gmail.com> wrote: > > Hi, > > today I moved to Pharo5. It is great to get feedback and solutions for > problems so quickly. It is a pleasure to work with Pharo and to have the > community. I am grateful for having this. > > I have one comment. I don't want to complain, I can use it but I was > wondering about the new position and size of the debugger buttons. > > There is a longer distance now from code text pane to the buttons - I see > this as disadvantage to earlier versions of Pharo from the user experience. > The buttons are a lot of smaller - same disadvantage - both if you use the > mouse. > > Ok, after seeing that, I thought "Sabine, you should use keyboard shortcuts > here, too" (I use much of them but interesting - til now not in the > debugger). > > Then I saw the shortcuts for > Proceed cmd+r > Restart cmd-shift-a > Into cmd-e > over cmd-shift-o > through cmd-shift-t > > especially into, over and through have so different key combinations, two > with shift, one without shift. When I debug, I often use for example > into-into-over-over-over-throuhg-through--into-into etc...and with the > combinations cmd-e and cmd-shit-e, it is more "finger-work". It would be > better to have all those shortcuts with or all shortcuts without shift. And > the letters not so far away at the keyboard (e-o-t) > > This is only my opinion and my first impression after one day with Pharo5. > I > am sure, after a few days, I forgot that this was uncomfortable because I > have the shortcuts coming automatically into my fingers. > > Regards > Sabine > > > > > > > -- > View this message in context: > http://forum.world.st/One-comment-to-new-Pharo5-debugger-tp4897390.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com > <http://nabble.com>. > > > -- > www.tudorgirba.com > www.feenk.com > > "Every thing should have the right to be different." > > > > >

June 4, 2016

Re: [Pharo-users] One comment to new Pharo5 debugger

by Tudor Girba

Hi, > On Jun 4, 2016, at 12:18 PM, Sabine Manaa <manaa.sabine(a)gmail.com> wrote: > > Hi Tudor, > > thank you for the explanation, which explains the situation. > > Speaking only for me: I never used custom debuggers, I always used the default debugger in different smalltalk IDEs and so, I am used to a kind of "standardâ. That is because they do not exist anywhere else at this point in time :). > But as your signature points out "Every thing should have the right to be different." :-) Indeed :) > I can live with the given alternatives (create my now shortcuts and move the buttons). Great. Please note that there is an open issue with externalizing shortcuts which we did not get to address until Pharo 5, but we will certainly address for Pharo 6. > I ask myself, how many people know, need and use specific debuggers. This is absolutely a legitimate question. I will open another thread to address it. But, given that this is a new concept, it is very important for us to get your opinion on what works and what does not. We think there is value in the concept of moldability, but we are at the beginning and I am convinced we need more iteration to strike a better balance between extensibility and usability. > And in this context, which debugger should be the "default" debugger. Perhaps it is an important point for the first impression of new people coming to pharo (coming from other smalltalks) and people coming from other languages. If you come to a new IDE, I assume it will not be the first step to customize the debugger (at least not for me). Indeed, it will not be the first step. Just like it will not be the first step to extend the inspector. The main use case is for the framework builders to ship custom debuggers specific for their frameworks. See more in the other thread. > But, again - for me everything is fine as it is. I love working with pharo an I was very impressed by several new features of the new version. Eg. the new integrated code critics is an insanely great new feature (which is also not like this in other smalltalk IDEs!!). Indeed, this is a useful addition and we need to make more room for this our tools. Cheers, Doru > Regards > Sabine > > View this message in context: Re: One comment to new Pharo5 debugger > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. -- www.tudorgirba.com www.feenk.com "The coherence of a trip is given by the clearness of the goal."

June 4, 2016

Re: [Pharo-users] [UFFI] Call a function where argument type is char ** (argv)

by Esteban Lorenzano

Hi, but this will not work either (I just realised). This is complicated matter and confuses many (even me, some times :P). I will try explain. Technically, when you do array := (FFIExternalArray externalNewType: 'void*' size: parameters size) autoRelease. you are declaring (in C) (void*)[] array; which (in C) is synonym of: void** which means that as soon as you declare your array, you already have a void** then, your call has to be: ... self prim_initEmbeddedRargc: parameters size argv: externalArray. with call of: self ffiCall: #(int Rf_initEmbeddedR(int argc, FFIExternalArrayOfStrings argv)) (is better to declare a subclass of FFIExternalArray to be clear about your purpose). or the other way. Since UFFI cannot determine if an ExternalAddress is a pointer (void*) or a pointer to a pointer (void**), because for C, at the end, they are exactly the same, you need to declare as this: self prim_initEmbeddedRargc: parameters size argv: externalArray getHandle. with call of: self ffiCall: #(int Rf_initEmbeddedR(int argc, void *argv)) remarks: 1) you need to declare it as âvoid*" because UFFI will box any arity > [object natural arity], which in arrays is 1 (then, if you pass ** it will box it into a âwrongâ void***â¦ bad. 2) in this case, since you are passing a handle (a pointer), you do not need/want to subclass FFIExternalArray. Finally, a third way (not tested), is just doing: self prim_initEmbeddedRargc: parameters size argv: externalArray getHandle. with call of: self ffiCall: #(int Rf_initEmbeddedR(int argc, oop argv)) in this case, it will pass the handle (pointer) âas isâ, without transformation. This should work but I never tested it. Maybe in terms of clarity, last form is betterâ¦ I donât know :P confusing? yes but it is because is very hard to determine/parse/interpret pointer arities and keep the calls efficient, in a moment we need to put a limit in automatic translations. Esteban > On 04 Jun 2016, at 10:10, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > > sorry late response, I just missed this mails. > > butâ¦ I do not have much to sayâ¦ what you did should work. > Except (I think Iâd need to look at your code closer) you need to change the argument of argv to FFIExternalArray*, or you need to pass the handle to the function. Something like this: > > > | externalArray parameters | > > parameters := #('R' '--no-save' 'silent'). > externalArray := (FFIExternalArray externalNewType: 'void*' size: parameters size) autoRelease. > parameters withIndexDo: [ :string :index | > externalArray at: index put: (ExternalAddress fromString: string) autoRelease ]. > self prim_initEmbeddedRargc: parameters size argv: externalArray getHandle > > (with same primitive call) > > or without the #getHandle message and a primitive call: > > self ffiCall: #(int Rf_initEmbeddedR(int argc, FFIExternalArray* argv)) > > AFAIK, that should workâ¦ if not Iâd need to take a better look, because is maybe a bug :P > > Esteban > >> On 03 Jun 2016, at 18:50, Blondeau Vincent <vincent.blondeau(a)worldline.com> wrote: >> >> Hello, >> >> So, we tried with Thibault Raffaillac and we succeed to have this kind of code: >> >> >> | externalArray | >> parameters := #('R' '--no-save' 'silent'). >> [ externalArray := FFIExternalArray externalNewType: 'void*' size: parameters size. >> parameters >> withIndexDo: [ :string :index | externalArray at: index put: (ExternalAddress fromString: string) ]. >> self prim_initEmbeddedRargc: parameters size argv: externalArray ] >> ensure: [ externalArray >> ifNotNil: [ externalArray do: [ :item | item ifNotNil: [ :e | e free ] ]. >> externalArray free ] ] >> >> with a primitive call: >> self ffiCall: #(int Rf_initEmbeddedR(int argc, char ** argv)) >> >> However, it still doesn't work because the VM is crashing during the call to the primitive. >> >> Does the translation from the Nativeboost version is accurate? >> >> Thanks in advance for your help, >> >> Vincent >> >>> -----Message d'origine----- >>> De : Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] De la part de >>> Julien Delplanque >>> EnvoyÃ© : mercredi 1 juin 2016 18:49 >>> Ã : pharo-users(a)lists.pharo.org >>> Objet : Re: [Pharo-users] [UFFI] Call a function where argument type is char ** >>> (argv) >>> >>> Hello, >>> >>> I asked a simililar question some days ago, maybe this [1] can help. >>> >>> Regards, >>> >>> Julien >>> >>> Links: >>> >>> [1]: >>> http://forum.world.st/Unified-FFI-pointer-of-String-as-function-parameter- >>> td4898066.html >>> >>> >>> On 31/05/16 16:28, Blondeau Vincent wrote: >>>> TL;DR: How to pass as argument an array of Strings (char **) with Unified- >>> FFI? >>>> >>>> Vincent >>>> >>>> De : Blondeau Vincent >>>> EnvoyÃ© : mercredi 25 mai 2016 13:58 >>>> Ã : Pharo Development List >>>> Objet : [UFFI] Call a function where argument type is char ** (argv) >>>> >>>> Hello, >>>> >>>> I have written a R bridge in Pharo and I would like to migrate it from >>> NativeBoost to UFFI. >>>> Most of the changes are easy to do but I am stuck to a double pointer >>> problem. >>>> I have to call the function: int Rf_initEmbeddedR(int argc, char ** argv). I >>> know how to give the int but the char ** is a problem. It is an array of Strings. >>>> >>>> With NB, I managed to have this (working) code: >>>> "This is 32bit... too bad..." >>>> strings := OrderedCollection new. >>>> par := NativeBoost allocate: 4 * params size. >>>> params >>>> keysAndValuesDo: [ :i :each | >>>> | str | >>>> str := each asNBExternalString. >>>> strings add: str. >>>> par nbUInt32AtOffset: (i - 1) * 4 put: str value ]. >>>> self prim_initEmbeddedRargc: params size argv: par ] >>>> ensure: [ >>>> "Free the memory we allocated" >>>> par ifNotNil: [ par free ]. >>>> strings ifNotNil: [ >>>> strings do: [ :each | each free ] ] ] >>>> >>>> With a primitive call: >>>> Self nbCall: #(int Rf_initEmbeddedR(int argc, char *argv)) >>>> >>>> Do I still need to create my own array of strings or FFI creates it for me? >>> How? >>>> >>>> Thanks in advance for your answers, >>>> >>>> Vincent >>>> >>>> >>>> >>> !!!*************************************************************** >>> **** >>>> ****************** "Ce message et les piÃ¨ces jointes sont >>>> confidentiels et rÃ©servÃ©s Ã l'usage exclusif de ses destinataires. Il peut >>> Ã©galement Ãªtre protÃ©gÃ© par le secret professionnel. Si vous recevez ce >>> message par erreur, merci d'en avertir immÃ©diatement l'expÃ©diteur et de le >>> dÃ©truire. L'intÃ©gritÃ© du message ne pouvant Ãªtre assurÃ©e sur Internet, la >>> responsabilitÃ© de Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de >>> ce message. Bien que les meilleurs efforts soient faits pour maintenir cette >>> transmission exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã >>> cet Ã©gard et sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage >>> rÃ©sultant d'un virus transmis. >>>> >>>> This e-mail and the documents attached are confidential and intended >>> solely for the addressee; it may also be privileged. If you receive this e-mail in >>> error, please notify the sender immediately and destroy it. As its integrity >>> cannot be secured on the Internet, the Worldline liability cannot be triggered >>> for the message content. Although the sender endeavours to maintain a >>> computer virus-free network, the sender does not warrant that this >>> transmission is virus-free and will not be liable for any damages resulting >>> from any virus transmitted.!!!" >>>> >>> >> >> >> !!!************************************************************************************* >> "Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un virus transmis. >> >> This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.!!!" >> >

June 4, 2016

Re: [Pharo-users] One comment to new Pharo5 debugger

by Esteban Lorenzano

Hi, > On 04 Jun 2016, at 12:18, Sabine Manaa <manaa.sabine(a)gmail.com> wrote: > > Hi Tudor, > > thank you for the explanation, which explains the situation. > > Speaking only for me: I never used custom debuggers, I always used the default debugger in different smalltalk IDEs and so, one could say you never used custom debuggers because you never had the chance :) > I am used to a kind of "standard". But as your signature points out "Every thing should have the right to be different." :-) > > I can live with the given alternatives (create my now shortcuts and move the buttons). > > I ask myself, how many people know, need and use specific debuggers. And in this context, which debugger should be the "default" debugger. Perhaps it is an important point for the first impression of new people coming to pharo (coming from other smalltalks) and people coming from other languages. If you come to a new IDE, I assume it will not be the first step to customize the debugger (at least not for me). > > But, again - for me everything is fine as it is. I love working with pharo an I was very impressed by several new features of the new version. Eg. the new integrated code critics is an insanely great new feature (which is also not like this in other smalltalk IDEs!!). Iâm sure we can find a solution that appeals everybody, we just need to reflect/experiment a bit more. cheers! Esteban ps: Iâm also think the highest impact for this version (the one who can more directly help users) is QAâ¦ and Iâm very thankful yuri made such a tool. Next versions will start to feel the impact of reflectivity (breakpoints being just the first âsmellâ of what can be achieved there, but we are just starting to build the tools for benefit from it... > > Regards > Sabine > > View this message in context: Re: One comment to new Pharo5 debugger <http://forum.world.st/One-comment-to-new-Pharo5-debugger-tp4897390p4899132.…> > Sent from the Pharo Smalltalk Users mailing list archive <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> at Nabble.com.

June 4, 2016

Re: [Pharo-users] One comment to new Pharo5 debugger

by Sabine Manaa

Hi Tudor, thank you for the explanation, which explains the situation. Speaking only for me: I never used custom debuggers, I always used the default debugger in different smalltalk IDEs and so, I am used to a kind of "standard". But as your signature points out "Every thing should have the right to be different." :-) I can live with the given alternatives (create my now shortcuts and move the buttons). I ask myself, how many people know, need and use specific debuggers. And in this context, which debugger should be the "default" debugger. Perhaps it is an important point for the first impression of new people coming to pharo (coming from other smalltalks) and people coming from other languages. If you come to a new IDE, I assume it will not be the first step to customize the debugger (at least not for me). But, again - for me everything is fine as it is. I love working with pharo an I was very impressed by several new features of the new version. Eg. the new integrated code critics is an insanely great new feature (which is also not like this in other smalltalk IDEs!!). Regards Sabine -- View this message in context: http://forum.world.st/One-comment-to-new-Pharo5-debugger-tp4897390p4899132.… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 4, 2016

Re: [Pharo-users] [UFFI] Call a function where argument type is char ** (argv)

by Esteban Lorenzano

Hi, sorry late response, I just missed this mails. butâ¦ I do not have much to sayâ¦ what you did should work. Except (I think Iâd need to look at your code closer) you need to change the argument of argv to FFIExternalArray*, or you need to pass the handle to the function. Something like this: | externalArray parameters | parameters := #('R' '--no-save' 'silent'). externalArray := (FFIExternalArray externalNewType: 'void*' size: parameters size) autoRelease. parameters withIndexDo: [ :string :index | externalArray at: index put: (ExternalAddress fromString: string) autoRelease ]. self prim_initEmbeddedRargc: parameters size argv: externalArray getHandle (with same primitive call) or without the #getHandle message and a primitive call: self ffiCall: #(int Rf_initEmbeddedR(int argc, FFIExternalArray* argv)) AFAIK, that should workâ¦ if not Iâd need to take a better look, because is maybe a bug :P Esteban > On 03 Jun 2016, at 18:50, Blondeau Vincent <vincent.blondeau(a)worldline.com> wrote: > > Hello, > > So, we tried with Thibault Raffaillac and we succeed to have this kind of code: > > > | externalArray | > parameters := #('R' '--no-save' 'silent'). > [ externalArray := FFIExternalArray externalNewType: 'void*' size: parameters size. > parameters > withIndexDo: [ :string :index | externalArray at: index put: (ExternalAddress fromString: string) ]. > self prim_initEmbeddedRargc: parameters size argv: externalArray ] > ensure: [ externalArray > ifNotNil: [ externalArray do: [ :item | item ifNotNil: [ :e | e free ] ]. > externalArray free ] ] > > with a primitive call: > self ffiCall: #(int Rf_initEmbeddedR(int argc, char ** argv)) > > However, it still doesn't work because the VM is crashing during the call to the primitive. > > Does the translation from the Nativeboost version is accurate? > > Thanks in advance for your help, > > Vincent > >> -----Message d'origine----- >> De : Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] De la part de >> Julien Delplanque >> EnvoyÃ© : mercredi 1 juin 2016 18:49 >> Ã : pharo-users(a)lists.pharo.org >> Objet : Re: [Pharo-users] [UFFI] Call a function where argument type is char ** >> (argv) >> >> Hello, >> >> I asked a simililar question some days ago, maybe this [1] can help. >> >> Regards, >> >> Julien >> >> Links: >> >> [1]: >> http://forum.world.st/Unified-FFI-pointer-of-String-as-function-parameter- >> td4898066.html >> >> >> On 31/05/16 16:28, Blondeau Vincent wrote: >>> TL;DR: How to pass as argument an array of Strings (char **) with Unified- >> FFI? >>> >>> Vincent >>> >>> De : Blondeau Vincent >>> EnvoyÃ© : mercredi 25 mai 2016 13:58 >>> Ã : Pharo Development List >>> Objet : [UFFI] Call a function where argument type is char ** (argv) >>> >>> Hello, >>> >>> I have written a R bridge in Pharo and I would like to migrate it from >> NativeBoost to UFFI. >>> Most of the changes are easy to do but I am stuck to a double pointer >> problem. >>> I have to call the function: int Rf_initEmbeddedR(int argc, char ** argv). I >> know how to give the int but the char ** is a problem. It is an array of Strings. >>> >>> With NB, I managed to have this (working) code: >>> "This is 32bit... too bad..." >>> strings := OrderedCollection new. >>> par := NativeBoost allocate: 4 * params size. >>> params >>> keysAndValuesDo: [ :i :each | >>> | str | >>> str := each asNBExternalString. >>> strings add: str. >>> par nbUInt32AtOffset: (i - 1) * 4 put: str value ]. >>> self prim_initEmbeddedRargc: params size argv: par ] >>> ensure: [ >>> "Free the memory we allocated" >>> par ifNotNil: [ par free ]. >>> strings ifNotNil: [ >>> strings do: [ :each | each free ] ] ] >>> >>> With a primitive call: >>> Self nbCall: #(int Rf_initEmbeddedR(int argc, char *argv)) >>> >>> Do I still need to create my own array of strings or FFI creates it for me? >> How? >>> >>> Thanks in advance for your answers, >>> >>> Vincent >>> >>> >>> >> !!!*************************************************************** >> **** >>> ****************** "Ce message et les piÃ¨ces jointes sont >>> confidentiels et rÃ©servÃ©s Ã l'usage exclusif de ses destinataires. Il peut >> Ã©galement Ãªtre protÃ©gÃ© par le secret professionnel. Si vous recevez ce >> message par erreur, merci d'en avertir immÃ©diatement l'expÃ©diteur et de le >> dÃ©truire. L'intÃ©gritÃ© du message ne pouvant Ãªtre assurÃ©e sur Internet, la >> responsabilitÃ© de Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de >> ce message. Bien que les meilleurs efforts soient faits pour maintenir cette >> transmission exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã >> cet Ã©gard et sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage >> rÃ©sultant d'un virus transmis. >>> >>> This e-mail and the documents attached are confidential and intended >> solely for the addressee; it may also be privileged. If you receive this e-mail in >> error, please notify the sender immediately and destroy it. As its integrity >> cannot be secured on the Internet, the Worldline liability cannot be triggered >> for the message content. Although the sender endeavours to maintain a >> computer virus-free network, the sender does not warrant that this >> transmission is virus-free and will not be liable for any damages resulting >> from any virus transmitted.!!!" >>> >> > > > !!!************************************************************************************* > "Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un virus transmis. > > This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.!!!" >

June 4, 2016

Re: [Pharo-users] One comment to new Pharo5 debugger

by Tudor Girba

Hi Sabine (and others that asked this question), Thanks for the feedback. Sorry for the delayed reply, but I am traveling these days and I have limited online time. Also, this email took some time to write (I started it about a week ago). I will answer the buttons issue. The reason they are in a different place than where they used to be is related to new constraints that come with the new debugger. While the default interface looks like a regular debugger, the main feature of the GTDebugger is that it can be customized to match a specific domain or library. Let me provide an example of a scenario of debugging PetitParser: PPArithmeticParser parse: '1+2*3^(34-2)â The default debugger looks like this: But, because we have PetitParser code on the stack, we can switch to a custom debugger: This one also features the input stream next to the code. Also, note that the stack received 3 new button actions. But, this is not all. Next to the source, there are other tabs, and we can switch to one of those: This one shows the source as well, but in a graphical form. So, if we step back and talk about the buttons, you will see that if we would have put the buttons on the source tabs, you have had no way to advance in this state. We could have also duplicated behavior and put the buttons on the new presentation as well, but the space is much smaller and since we now have large buttons instead of only icons we needed to deal with that as well. We encountered similar situations in other debuggers (not all, though). But, from a more point of view, the actions act on the stack. So, if we take an object-oriented approach for designing the UI, it makes sense to place those actions next to the context they act on. All these reasons made us choose to put them next to the stack and not next to the source. We certainly understand that this is a departure from the classic debugger and perhaps this is not the best way of doing things, but that was the rationale we went through. I would be happy to hear other suggestions, but please understand that we need to take into account the full spectrum of constraints when choosing solutions. In any case, the idea of this debugger is that you can change it in the way you want and customize it specifically for your needs. We still need to document how to do that, but if someone wants to start creating a custom debugger we could use the experience to drive the documentation. Does this explain the situation? Cheers, Doru > On May 25, 2016, at 9:43 PM, Sabine Manaa <manaa.sabine(a)gmail.com> wrote: > > Hi, > > today I moved to Pharo5. It is great to get feedback and solutions for > problems so quickly. It is a pleasure to work with Pharo and to have the > community. I am grateful for having this. > > I have one comment. I don't want to complain, I can use it but I was > wondering about the new position and size of the debugger buttons. > > There is a longer distance now from code text pane to the buttons - I see > this as disadvantage to earlier versions of Pharo from the user experience. > The buttons are a lot of smaller - same disadvantage - both if you use the > mouse. > > Ok, after seeing that, I thought "Sabine, you should use keyboard shortcuts > here, too" (I use much of them but interesting - til now not in the > debugger). > > Then I saw the shortcuts for > Proceed cmd+r > Restart cmd-shift-a > Into cmd-e > over cmd-shift-o > through cmd-shift-t > > especially into, over and through have so different key combinations, two > with shift, one without shift. When I debug, I often use for example > into-into-over-over-over-throuhg-through--into-into etc...and with the > combinations cmd-e and cmd-shit-e, it is more "finger-work". It would be > better to have all those shortcuts with or all shortcuts without shift. And > the letters not so far away at the keyboard (e-o-t) > > This is only my opinion and my first impression after one day with Pharo5. I > am sure, after a few days, I forgot that this was uncomfortable because I > have the shortcuts coming automatically into my fingers. > > Regards > Sabine > > > > > > > -- > View this message in context: http://forum.world.st/One-comment-to-new-Pharo5-debugger-tp4897390.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > -- www.tudorgirba.com www.feenk.com "Every thing should have the right to be different."

June 4, 2016

Re: [Pharo-users] Saving to local git and "Loading all file names from http://...pharo5/inbox"

by Dale Henrichs

On 6/3/16 2:43 AM, Otto Behrens wrote: >> For FileTree repos it is even better to just load the package (Monticello >> does a good job of only loading the changed packages and we're looking at >> packages already on disk) ... ... I have an extension to Metacello for >> Filetree repos (it's only been around for about 3 years) that ignores >> version numbers and "loads" all of the packages from the the repo (I >> mentioned _this_ to Thierry:) ... which for FileTree repos is actually the >> proper behavior ... I happen to be very busy at the moment so I don't have >> time to blow the dust off of that extension ... the big gotcha is everyone >> has to have the extension present in their image for this kind of thing to >> work and AFAIK pharo is not kept up-to-date with the latest versions that I >> publish on github, so I'm afraid that much breakage would ensure if only a >> few individuals started using this extension ... Seems to be that we're >> stuck between a rock and a had place... I wish there was a better way to >> keep the Metacello distribution up-to-date in images that I have no control >> over ... >> >> FWIW, I've found that if I manually flush the cache for each package before >> I save it, I don't have to wait the minute or so for all of the repos to be >> refreshed ... > Dale, will you please publish this stuff somewhere, with dust on, as > is? (Or tell us where we can find it). Well let's see there's the Metacello-Cypress package is in the Metacello repo[1] and the following should load the Cypress support into an image with Metacello already loaded: Metacello image baseline: 'Metacello'; load: ' Cypress' To use the Cypress support, implement a #projectClass method in your BaselineOf that returns MetacelloCypressBaselineProject: projectClass ^MetacelloCypressBaselineProject and you should be in business ... IIRC the MetacelloCypressBaselineProject should be usable with any BaselineOf. The only difference for Cypress is that Monticello versions are ignored when making loading decisions --- at least that's the intent. Before going full scale, we'd need to add some tests for the Cypress project and of course make sure that the Cypress support gets loaded by default ... [1] https://github.com/dalehenrich/metacello-work/tree/master/repository/Metace… > We've just battled sooo much in this area. I wonder if it is worth it > to think again about this whole git / monticello / metacello thing. > For me, it's just too much to comprehend. As soon as I dig into > something here, I get lost within minutes. > > I believe the complexity has to do with trying to maintain too many > different ways of solving the problem. We are trying to keep things > (Monticello / Metacello) working with or without git or filetree or > whatever else people are using. > > I would really like to do merging in git and just have a fast and > simple way of loading / compiling into an image (and GemStone). I do > not want a package cache, 3 way merging and all the other things, > because it makes what I end up with unpredictable. But you see, other > people want to work in other ways, which I understand. My perception > is that the result is messy. > > We should try to strive more towards *fewer* ways of doing things, > without killing innovation to try different ways. It feels as if there > are enormous, yet very incomplete silos of efforts to solve problems. > I basically agree with everything you say here. I added the Cypress package support several years ago when Richard Sargent wrote a Cypress implementation for the base GemStone[2], so we've had the bits a pieces necessary for a cleaner simpler mechanism for a while at least for GemStone ... I would like to distinguish between Cypress and FileTree. FileTree was created (by you:) to support disk-based repos while maintaining full Monticello compatibility. Over the years I've (stubbornly) maintained that the Monticello meta data be preserved in FileTree repositories. By preserving Monticello meta data, the packages can be easily moved between FileTree and SmalltalkHub, etc. while faithfully preserving the Monticello ancestry. Maintaining Monticello meta data is critical for folks to be able to "dip their toe into the git pool" while preserving Monticello ancestry. When I say "Cypress" (as opposed to FileTree), I think of a stripped down implementation of FileTree where Monticello meta data is not stored on disk and, perhaps more importantly the package loading code, in-image package management and tool support is also stripped down to support a simple model where package history and version numbers are non-existent. This particular model is aimed at projects that spend their entire lives in "git" repos and there is no desire, nor need to keep a parallel ancestry in the Monticello meta data and I think that what you are asking for ... in fact with Cypress package names do not need any package meta data ... the SHA of the commit is all that is needed to uniquely identify packages [in tODE the development environment is focused on the Metacello project and the package is not really the focus, so right now the Metacello registry is capable of tracking the SHA of the commit used to load a _project_, so I don't think that a package needs to have any additional meta data like UUID or version number or and the SHA of the commit at _project_ load time is all that is needed] For Pharo, I think that GitFileTree provides you with support for a metadata-less disk footprint, but the in-image support is still based on Monticello --- at least that's what I understand about GitFileTree, since up to now I haven't spent any time working with it ... that will change this summer as I am working on a project in Pharo5. GitFileTree is an extension of the "FileTree model" in that it is compatible with the current in-image tools that all pretty much expect Monticello packages --- this approach is needed because it is a big job to incorporate an alternate source code management scheme in the in-image tools across the board ... If one were to switch the pharo tool focus from the _package_ (Monticello Browser) to the the _project_ (Project Browser) there would be additional work to be done: 'save' of project means save all dirty packages in project as well as a `git commit`, 'diff' of project means show changes for all dirty packages in project, and there would be analogs for 'load', 'revert', 'history' etc. For GemStone, I have written tODE to be git-aware from the beginning and I have built tools to support Cypress package management as well[3] although they _are_ 3 years old and would deserve additional work ... Internally we are seriously considering adding Cypress support to the base image for the GemStone 3.4 release and of course in the process of doing that work, I assume that we'd make the code available for use in 3.2 and 3.3 as well. In the short term I think that a combination of Cypress package support from Metacello, GitFileTree in Pharo and the updating of the Cypress tools for tODE will allow you to share packages between Pharo and GemStone without needing to create and maintain Monticello meta data ... in the midterm Cypress support is slated for this year and if necessary I can make changes to the current tODE FileTree implementation to allow the writing of metadata-less packages -- I think GitFileTree records whether or not a repository is metadata-less in a repository property file that I can use if necessary ... Does this make sense? Dale [2] https://github.com/rjsargent/CypressReferenceImplementation [3] https://github.com/dalehenrich/tode/tree/master/repository/Topez-Server-Cyp…

June 3, 2016