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

[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  
> 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-boun...@lists.pharo.org] De la part de
>> Julien Delplanque
>> Envoyé : mercredi 1 juin 2016 18:49
>> À : pharo-users@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é 

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

[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.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

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

[Esteban Lorenzano]

Hi, 

> On 04 Jun 2016, at 12:18, Sabine Manaa  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 
> 
> Sent from the Pharo Smalltalk Users mailing list archive 
>  at Nabble.com.

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

[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  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  
>> 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-boun...@lists.pharo.org] De la part de
>>> Julien Delplanque
>>> Envoyé : mercredi 1 juin 2016 18:49
>>> À : pharo-users@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 

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

[Tudor Girba]

Hi,

> On Jun 4, 2016, at 12:18 PM, Sabine Manaa  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."

[Pharo-users] the impact of moldability

[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."

[Pharo-users] Issue on Seaside beginning

[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
cheikho...@gmail.com

Re: [Pharo-users] Issue on Seaside beginning

[Cyril Ferlicot D.]

Le 04/06/2016 19:00, Cheikhou Oumar KA a écrit :
> 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
> 
> 
> Images intégrées 1
> 
> Any help is welcome.
> 
> Thanks
> 
> -- 
> /*Cheikhou Oumar KA */
> 奥 马 尔 ·谢 赫 ·嘉*/
> /*Doctorant Informatique
> cheikho...@gmail.com 
> 
> 
> 

Hi,

I think I already got this problem when I loaded Seaside 3.2 in an image
where Seaside 3.1 was present.

I'm not sure it's the same problem and I don't have the time to look at
it but maybe this can help others to find a solution.

-- 
Cyril Ferlicot

http://www.synectique.eu

165 Avenue Bretagne
Lille 59000 France



signature.asc
Description: OpenPGP digital signature

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

[Tudor Girba]

Hi,

> On Jun 4, 2016, at 7:09 PM, Ben Coman  wrote:
> 
> 
> 
> On Sat, Jun 4, 2016 at 11:28 PM, Gabriel Cotelli  wrote:
> 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).
> 
> Interesting idea.  Only the [Stack] tab is a bit lonely over there on the 
> right.  Perhaps the tab could still be on the left, with the buttons left 
> justified against it?
> 
> btw, are there any use cases for multiple stack tabs?

Do you mean if there are cases for seeing the stack in different ways or do you 
mean something else?

Cheers,
Doru

> cheers -ben
>  
> 
> 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  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  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-

Re: [Pharo-users] Issue on Seaside beginning

[Cheikhou Oumar KA]

> Hi,

> I think I already got this problem when I loaded Seaside 3.2 in an image
> where Seaside 3.1 was present.

Thanks for this.


2016-06-04 17:10 GMT+00:00 Cyril Ferlicot D. :

> Le 04/06/2016 19:00, Cheikhou Oumar KA a écrit :
> > 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
> >
> >
> > Images intégrées 1
> >
> > Any help is welcome.
> >
> > Thanks
> >
> > --
> > /*Cheikhou Oumar KA */
> > 奥 马 尔 ·谢 赫 ·嘉*/
> > /*Doctorant Informatique
> > cheikho...@gmail.com 
> >
> >
> >
>
> Hi,
>
> I think I already got this problem when I loaded Seaside 3.2 in an image
> where Seaside 3.1 was present.
>
> I'm not sure it's the same problem and I don't have the time to look at
> it but maybe this can help others to find a solution.
>
> --
> Cyril Ferlicot
>
> http://www.synectique.eu
>
> 165 Avenue Bretagne
> Lille 59000 France
>
>


-- 
*Cheikhou Oumar KA *
奥 马 尔 ·谢 赫 ·嘉
Doctorant Informatique
cheikho...@gmail.com

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

[Ben Coman]

On Sun, Jun 5, 2016 at 1:17 AM, Tudor Girba  wrote:
> Hi,
>
>> On Jun 4, 2016, at 7:09 PM, Ben Coman  wrote:
>>
>>
>>
>> On Sat, Jun 4, 2016 at 11:28 PM, Gabriel Cotelli  wrote:
>> 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).
>>
>> Interesting idea.  Only the [Stack] tab is a bit lonely over there on the 
>> right.  Perhaps the tab could still be on the left, with the buttons left 
>> justified against it?
>>
>> btw, are there any use cases for multiple stack tabs?
>
> Do you mean if there are cases for seeing the stack in different ways or do 
> you mean something else?

I meant, is the [Stack] tab really required?  Will there ever be a
second tab? Could the buttons be the sole occupant of that row -
beneath the stack pane?

Actually do like the idea of having a bottom hanging [Stack] tab
directly opposing the [Source] tab.
Could the buttons be left justified against that, and then if a second
tab ever comes along, slide the buttons to the right a little?

cheers -ben

>
> Cheers,
> Doru
>
>> cheers -ben
>>
>>
>> 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  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  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 a

Re: [Pharo-users] Issue on Seaside beginning

[stepharo]

Hi  Cheikhou

We will have a look. I will contact Luc and Damien because I do not 
follow the Seaside set up.


May be we messed up with the setup of the seaside image we gave you.

Did you save your code?

So that you can reload it with the

https://ci.inria.fr/pharo-contribution/job/Seaside/

Seaside3.2



You got a problem with such image

https://ci.inria.fr/pharo-contribution/job/PharoWeb/PHARO=50,VERSION=stable,VM=vm/lastSuccessfulBuild/artifact/PharoWeb.zip

do you have your code published so that I try to reproduce your problem?

Sorry for the inconvenience.


Stef

Le 4/6/16 à 19:00, Cheikhou Oumar KA a écrit :

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
Images intégrées 1

Any help is welcome.

Thanks

--
/*Cheikhou Oumar KA */
奥 马 尔 ·谢 赫 ·嘉*/
/*Doctorant Informatique
cheikho...@gmail.com 

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

[Ben Coman]

On Jun 4, 2016 14:11, "Ben Coman"  wrote:
>
>>
>>
>> On Sat, Jun 4, 2016 at 11:28 PM, Gabriel Cotelli 
>> wrote:
>>
>>> 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).
>>>
>>
>> Interesting idea.  Only the [Stack] tab is a bit lonely over there on the
>> right.  Perhaps the tab could still be on the left, with the buttons left
>> justified against it?
>>
>>
On Sun, Jun 5, 2016 at 1:36 AM, Gabriel Cotelli  wrote:

> Well I put the buttons on the left on purpose because in the case you're
> debugging source code the content tends to be on the left half of the
> screen.  So this keeps the actions close to the decision on what to use.
>
I do agree.  Here is my mockup, dependent on the number of [Stack] tabs
expected.



cheers -ben

Re: [Pharo-users] [Moose-dev] Re: the impact of moldability

[Tudor Girba]

Hi,

> On Jun 4, 2016, at 7:34 PM, Ben Coman  wrote:
> 
> Nice read and some interesting statistics.

Thanks

> It makes sense when laid
> out like that, but its a question of internalising the knowledge to
> make use of moldability more often.

Indeed. This is a challenge. In this regard, picking specific scenarios and 
asking questions about how to deal with them could help us build tutorials.

> 
> One small edit...
> We are the beginning
> ==> We are at the beginning

Fixed.

Doru



> 
> cheers -ben
> 
> On Sun, Jun 5, 2016 at 12:45 AM, Tudor Girba  wrote:
>> 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."
>> 
>> ___
>> Moose-dev mailing list
>> moose-...@list.inf.unibe.ch
>> https://www.list.inf.unibe.ch/listinfo/moose-dev
> ___
> Moose-dev mailing list
> moose-...@list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev

--
www.tudorgirba.com
www.feenk.com

"Being happy is a matter of choice."

Re: [Pharo-users] the impact of moldability

[stepharo]

I like the way you react to my criticisms. In fact each time I complain 
you make progress. You should really thank me in fact.


And you can name me if it makes you feel better. ;)


Now what you should measure is the ratio

over engineering - complexity of the solution vs. spread of usage.

because over engineering means more code to maintain, more complex 
logic



For example, I think that the GTinspector is a success because the pane 
are nice and useful.


Now EyeInspector was also extensible so this is not the extensibility 
the point that is the difference in adoption:


this is the way people can extend it

the good widget support and better look


Now for Spotter I'm questionning the other scenarios that are not the 
main ones:

- find a class
- implementors
- refs
- senders
In fact on the 50 that you can find I have problems to see the others 
useful. You can argue and brainwash me still
when I look at me coding sessions I do not need more (do not tell me 
that this is because I do not how to use Spotter - I should be

the one that produces mooc videos showing this great tool).

For the debugger I looked at the code and this is less a problem than I 
thought (but this is based on Glamour and I do not like Glamour

with blocks with multiple arguments and dataflow).

Now the question is if you would have invested the time you spent in 
moldable but in an advanced debugger
with object based breakpoints, concurrent support, alias support (like 
the wormhole debugger of the phd of adrian) and back in time debugging 
which ones people would really choose: because so far I do not debug 
bytecode, nor petitparser.
And what I got is basically not much more than before. This is not 
because you show the test setup on the side of the stack that it is

useful to me.

Note that my remark is not incompatible with the fact that you could 
have a debugger framework that you can use

to support bytecode and petitparser debugging.

Stef

So you can claim what you feel and justify your actions still there are 
other ways to measure success.


Stef

Le 4/6/16 à 18:45, Tudor Girba a écrit :

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."

Re: [Pharo-users] Issue on Seaside beginning

[Cheikhou Oumar KA]

Hi Stef

> You got a problem with such image

>
https://ci.inria.fr/pharo-contribution/job/PharoWeb/PHARO=50,VERSION=stable,VM=vm/lastSuccessfulBuild/artifact/PharoWeb.zip
Yes I saved my code in Smalltalkhub. i loaded it in this new image and It
works perfectly.

May be there the problem come from the combination of seaside and teapot in
the same packagedon't know.

>Sorry for the inconvenience.

Don't worry. Thanks a lot. Now I can poursue my exercises.

Thanks



2016-06-04 18:06 GMT+00:00 stepharo :

> Hi  Cheikhou
>
> We will have a look. I will contact Luc and Damien because I do not follow
> the Seaside set up.
>
> May be we messed up with the setup of the seaside image we gave you.
>
> Did you save your code?
>
> So that you can reload it with the
>
> https://ci.inria.fr/pharo-contribution/job/Seaside/
>
> Seaside3.2
>
>
>
> You got a problem with such image
>
>
> https://ci.inria.fr/pharo-contribution/job/PharoWeb/PHARO=50,VERSION=stable,VM=vm/lastSuccessfulBuild/artifact/PharoWeb.zip
>
> do you have your code published so that I try to reproduce your problem?
>
> Sorry for the inconvenience.
>
>
> Stef
> Le 4/6/16 à 19:00, Cheikhou Oumar KA a écrit :
>
> 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
> cheikho...@gmail.com
>
>
>
>
>


-- 
*Cheikhou Oumar KA *
奥 马 尔 ·谢 赫 ·嘉
Doctorant Informatique
cheikho...@gmail.com

Re: [Pharo-users] [Moose-dev] how to set a code completion schema in GT inspector?

[Tudor Girba]

Not now. This would be another thing to approach from a moldable point of view.

Doru


> On May 27, 2016, at 3:55 PM, Alexandre Bergel  wrote:
> 
> Hi!
> 
> Is there a way to provide a strategy to complete code in GT?
> For example, if I would like to specialize the completion in case I am 
> writing a Roassal script...
> 
> Alexandre
> -- 
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> 
> 
> 
> ___
> Moose-dev mailing list
> moose-...@list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev

--
www.tudorgirba.com
www.feenk.com

"Reasonable is what we are accustomed with."

[Pharo-users] Pharo 5 hanging and crashing

[Gerry Weaver]

Hello All,

I am new to Pharo and Smalltalk in general. I have been experimenting with 
Pharo 5 trying to get acquainted with the environment and the language. I have 
been having some issues with the image hanging and crashing. This happens when 
trying code in the Play Ground and especially when stepping through code in the 
debugger. Has anyone had similar problems? Should I be using Pharo 4 instead?

I have been testing Pharo on Windows 8 64bit and Ubuntu 14.04 64bit. Could this 
be a 64bit issue?

Thanks

Re: [Pharo-users] the impact of moldability

[Tudor Girba]

Hi Stef,

> On Jun 4, 2016, at 8:38 PM, stepharo  wrote:
> 
> I like the way you react to my criticisms. In fact each time I complain you 
> make progress. You should really thank me in fact.

Thanks for reading.

I try my best to welcome criticism even when the tone is not appropriate. I do 
not always succeed.


> And you can name me if it makes you feel better. ;)

I do not take any pleasure in talking about persons. I take pleasure in talking 
about arguments. This is a post that I am writing since about 4 months. I have 
about 50 more in the pipeline. But, yes, you pushed me to finish this one and I 
am happy.


> Now what you should measure is the ratio
> 
>over engineering - complexity of the solution vs. spread of usage.
> 
>because over engineering means more code to maintain, more complex logic

I think we did that, too. For example, the GTInspector has 800 lines of code 
(including all utilities and several smaller browsers) which is less than the 
EyeInspector. At the same time Glamour (if you take away Brick which is a 
widget set) is about 10k lines of code which is the same as Spec.

For the domain of browsers, I think it proved to be quite appropriate and it 
made the code on top be tiny. Still, I think it’s too much code, and I think we 
can do a better job in Bloc to support workflows.


> For example, I think that the GTinspector is a success because the pane are 
> nice and useful.

It is a success because there is a fundamental need for it. And because the 
design process that produced it looked at that fundamental need.


> Now EyeInspector was also extensible so this is not the extensibility the 
> point that is the difference in adoption:
> 
>this is the way people can extend it

That is what the post says. Interestingly, it is the “scripting” thin API of 
the Glamour components which made this way of extending possible.


>the good widget support and better look

The look is important, but you are forgetting the interaction. This is key.


> Now for Spotter I'm questionning the other scenarios that are not the main 
> ones:
>- find a class
>- implementors
>- refs
>- senders
> In fact on the 50 that you can find I have problems to see the others useful. 
> You can argue and brainwash me still
> when I look at me coding sessions I do not need more (do not tell me that 
> this is because I do not how to use Spotter - I should be
> the one that produces mooc videos showing this great tool).

But, I never argued for that. I only argued that if you do not need it does not 
mean that others do not need it. In fact, the existence of extensions shows 
exactly the contrary.

You get a similar dynamics in the apps on the phone. Some people have a ton of 
apps, some people have very few apps, and the vast majority of people do not 
use the vast majority of apps. Yet, this does not mean that the apps are not 
useful. It simply means that when context plays an important role, you will get 
this type of distribution.

For example, last week I remember navigating Moose models, file systems, 
senders, implementors, packages, playground pages, remote snippets, examples, 
pragmas, loading from the catalog. So, for me, these are useful, but I do not 
need to convince you that they are useful. Now you can choose to have exactly 
the 4 searches you want. Spotter allows you to do just that.


> For the debugger I looked at the code and this is less a problem than I 
> thought

Thanks for looking at it.


> (but this is based on Glamour and I do not like Glamour
> with blocks with multiple arguments and dataflow).

Well … it happens that this strange design made the other tools cheap enough to 
produce a shift in the way we build tools. It is not perfect at all, in fact we 
do not want this code (only the essence) in the Bloc world anymore, but there 
is some quality in there I guess.


> Now the question is if you would have invested the time you spent in moldable 
> but in an advanced debugger
> with object based breakpoints, concurrent support, alias support (like the 
> wormhole debugger of the phd of adrian) and back in time debugging which ones 
> people would really choose

You seem to position this as an either/or type of problem. I do not think it is 
like that.

A key aspect in the GT Debugger is that it has no logic. All logic is in the 
DebuggerModel and was integrated a long time ago. That was about laying out the 
foundation for playing with all sorts of debuggers, including the ones you 
mention.

The result is that if people want to play they can and we will not have to 
choose either one or the other. We can have both at the same time and choose 
between them at runtime.


> : because so far I do not debug bytecode, nor petitparser.

You do not debug those because you do not develop with those packages :). I 
happen to have the need of debugging parsers, and this debugger makes a 
difference. The Glamour debugger also makes a difference for complicated 
wor

Re: [Pharo-users] Pharo 5 hanging and crashing

[Tudor Girba]

Hi,

Pharo 5 is the current release, and you should use this one :).

Do you have a specific scenario that we can use to reproduce the crashing 
behavior?

Cheers,
Doru


> On Jun 4, 2016, at 11:48 PM, Gerry Weaver  wrote:
> 
> Hello All,
>  
> I am new to Pharo and Smalltalk in general. I have been experimenting with 
> Pharo 5 trying to get acquainted with the environment and the language. I 
> have been having some issues with the image hanging and crashing. This 
> happens when trying code in the Play Ground and especially when stepping 
> through code in the debugger. Has anyone had similar problems? Should I be 
> using Pharo 4 instead?
>  
> I have been testing Pharo on Windows 8 64bit and Ubuntu 14.04 64bit. Could 
> this be a 64bit issue?
>  
> Thanks

--
www.tudorgirba.com
www.feenk.com

"What we can governs what we wish."

Re: [Pharo-users] Issue on Seaside beginning

[Luc Fabresse]

Hi Cheikhou,

Ok, this is good that you found a solution.
Can you post your solution on the MOOC forum to help other people that
might be blocked?

Thanks,

#Luc

2016-06-04 20:58 GMT+02:00 Cheikhou Oumar KA :

> Hi Stef
>
> > You got a problem with such image
>
> >
> https://ci.inria.fr/pharo-contribution/job/PharoWeb/PHARO=50,VERSION=stable,VM=vm/lastSuccessfulBuild/artifact/PharoWeb.zip
> Yes I saved my code in Smalltalkhub. i loaded it in this new image and It
> works perfectly.
>
> May be there the problem come from the combination of seaside and teapot
> in the same packagedon't know.
>
> >Sorry for the inconvenience.
>
> Don't worry. Thanks a lot. Now I can poursue my exercises.
>
> Thanks
>
>
>
> 2016-06-04 18:06 GMT+00:00 stepharo :
>
>> Hi  Cheikhou
>>
>> We will have a look. I will contact Luc and Damien because I do not
>> follow the Seaside set up.
>>
>> May be we messed up with the setup of the seaside image we gave you.
>>
>> Did you save your code?
>>
>> So that you can reload it with the
>>
>> https://ci.inria.fr/pharo-contribution/job/Seaside/
>>
>> Seaside3.2
>>
>>
>>
>> You got a problem with such image
>>
>>
>> https://ci.inria.fr/pharo-contribution/job/PharoWeb/PHARO=50,VERSION=stable,VM=vm/lastSuccessfulBuild/artifact/PharoWeb.zip
>>
>> do you have your code published so that I try to reproduce your problem?
>>
>> Sorry for the inconvenience.
>>
>>
>> Stef
>> Le 4/6/16 à 19:00, Cheikhou Oumar KA a écrit :
>>
>> 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
>> cheikho...@gmail.com
>>
>>
>>
>>
>>
>
>
> --
> *Cheikhou Oumar KA *
> 奥 马 尔 ·谢 赫 ·嘉
> Doctorant Informatique
> cheikho...@gmail.com
>
>
>
>

Re: [Pharo-users] Pharo 5 hanging and crashing

[Gerry Weaver]

Hi,

I'm afraid I don't have any steps to reproduce the issues at the moment. I was 
just playing around and it hung or crashed frequently enough that it became a 
bit tedious. I just wondered, if anyone else was having problems. It would seem 
that I may be alone in this, so I'll try to figure out what is going on.

Thanks


-Original Message-
From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of 
Tudor Girba
Sent: Saturday, June 4, 2016 4:56 PM
To: Any question about pharo is welcome 
Subject: Re: [Pharo-users] Pharo 5 hanging and crashing

Hi,

Pharo 5 is the current release, and you should use this one :).

Do you have a specific scenario that we can use to reproduce the crashing 
behavior?

Cheers,
Doru


> On Jun 4, 2016, at 11:48 PM, Gerry Weaver  wrote:
> 
> Hello All,
>  
> I am new to Pharo and Smalltalk in general. I have been experimenting with 
> Pharo 5 trying to get acquainted with the environment and the language. I 
> have been having some issues with the image hanging and crashing. This 
> happens when trying code in the Play Ground and especially when stepping 
> through code in the debugger. Has anyone had similar problems? Should I be 
> using Pharo 4 instead?
>  
> I have been testing Pharo on Windows 8 64bit and Ubuntu 14.04 64bit. Could 
> this be a 64bit issue?
>  
> Thanks

--
www.tudorgirba.com
www.feenk.com

"What we can governs what we wish."

[Pharo-users] Pharo MOOC: A propossed change on factorial

[Offray Vladimir Luna Cárdenas]

Hi all,

I'm advancing on the Pharo MOOC trying to catch the rest of the people. 
It has been a really interesting learning experience.


Now I'm making the Block lesson on week 2 and I have found the factorial 
example with its code. With the quality assistant It noticed no spaces 
at the beginning or end of the blocks and I'm also wondering how the 
factorial definition could be changed to give a more friendly message 
for non integer positive numbers, similar to the one it gives for 
negative number. For example, if I put "1.5 factorial" I get the "MNU: 
BoxedFloat64>>factorial".


What could the strategy in this case?

Cheers,

Offray

[Pharo-users] problem getting moose

[Ben Coman]

I wanted to try out Peter's XMI Analyser with Roassal and went to
download Moose but had a couple of problems.

First try...
In the Launcher under Common Tools, I downloaded and Moose 5.1(stable)
fine, but it is Pharo 4, so tried to download Moose 6.0(beta) -- but
got a problem - big pause, no progress bars, the later ZipArchive
reporting "Error: can't find EOCD position"

Second try...
The web site advises for Moose 6.0 to download the Moose code in a
Pharo 5.0 image per...
  Gofer new
 smalltalkhubUser: 'Moose' project: 'Moose';
 configuration;
 loadDevelopment.

Doing that in build 50760 download with the Launcher produced...
Could not resolve: Phexample [Phexample-NikoSchwarz.57] in
/home/ben/.local/share/Pharo/images/Moose6-50760/package-cache
http://www.squeaksource.com/Moose ERROR: 'GoferRepositoryError: Could
not access http://www.squeaksource.com/phexample: ZnInvalidUTF8:
Illegal leading byte for utf-8 encoding'

Could someone check if they see the same, or maybe my Internet is flakey atm?
(preferably someone who doesn't normally use Moose to avoid package
cache differences)

cheers -ben

Re: [Pharo-users] Pharo 5 hanging and crashing

[Tudor Girba]

Hi,

This is certainly not something that should happen. Pharo 5 is deemed ready for 
production and many of us are using it since a long time :).

It is still possible that you encountered a bug, and having a reproducible case 
can help us spot it.

Meanwhile, when you say crashing, do you mean that a debugger appeared, or that 
the image completely quitted? Was it because of a code that you run, or was it 
because of the interaction with tools?

Cheers,
Doru


> On Jun 5, 2016, at 3:42 AM, Gerry Weaver  wrote:
> 
> Hi,
> 
> I'm afraid I don't have any steps to reproduce the issues at the moment. I 
> was just playing around and it hung or crashed frequently enough that it 
> became a bit tedious. I just wondered, if anyone else was having problems. It 
> would seem that I may be alone in this, so I'll try to figure out what is 
> going on.
> 
> Thanks
> 
> 
> -Original Message-
> From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of 
> Tudor Girba
> Sent: Saturday, June 4, 2016 4:56 PM
> To: Any question about pharo is welcome 
> Subject: Re: [Pharo-users] Pharo 5 hanging and crashing
> 
> Hi,
> 
> Pharo 5 is the current release, and you should use this one :).
> 
> Do you have a specific scenario that we can use to reproduce the crashing 
> behavior?
> 
> Cheers,
> Doru
> 
> 
>> On Jun 4, 2016, at 11:48 PM, Gerry Weaver  wrote:
>> 
>> Hello All,
>> 
>> I am new to Pharo and Smalltalk in general. I have been experimenting with 
>> Pharo 5 trying to get acquainted with the environment and the language. I 
>> have been having some issues with the image hanging and crashing. This 
>> happens when trying code in the Play Ground and especially when stepping 
>> through code in the debugger. Has anyone had similar problems? Should I be 
>> using Pharo 4 instead?
>> 
>> I have been testing Pharo on Windows 8 64bit and Ubuntu 14.04 64bit. Could 
>> this be a 64bit issue?
>> 
>> Thanks
> 
> --
> www.tudorgirba.com
> www.feenk.com
> 
> "What we can governs what we wish."
> 
> 
> 
> 
> 
> 

--
www.tudorgirba.com
www.feenk.com

"Innovation comes in the least expected form. 
That is, if it is expected, it already happened."

Re: [Pharo-users] Pharo 5 hanging and crashing

[Gerry Weaver]

Hi,

I'm using the term "hanging" to mean that the image locked up or became 
unresponsive. When I use the term "crashing", I mean the image aborted. I have 
also seen a few cases where the image would hang first and then abort a few 
seconds later. This usually results after a few error windows have popped up. 
I'll try to keep track of when it happens again.

Thanks

-Original Message-
From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of 
Tudor Girba
Sent: Sunday, June 5, 2016 12:55 AM
To: Any question about pharo is welcome 
Subject: Re: [Pharo-users] Pharo 5 hanging and crashing

Hi,

This is certainly not something that should happen. Pharo 5 is deemed ready for 
production and many of us are using it since a long time :).

It is still possible that you encountered a bug, and having a reproducible case 
can help us spot it.

Meanwhile, when you say crashing, do you mean that a debugger appeared, or that 
the image completely quitted? Was it because of a code that you run, or was it 
because of the interaction with tools?

Cheers,
Doru


> On Jun 5, 2016, at 3:42 AM, Gerry Weaver  wrote:
> 
> Hi,
> 
> I'm afraid I don't have any steps to reproduce the issues at the moment. I 
> was just playing around and it hung or crashed frequently enough that it 
> became a bit tedious. I just wondered, if anyone else was having problems. It 
> would seem that I may be alone in this, so I'll try to figure out what is 
> going on.
> 
> Thanks
> 
> 
> -Original Message-
> From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of 
> Tudor Girba
> Sent: Saturday, June 4, 2016 4:56 PM
> To: Any question about pharo is welcome 
> Subject: Re: [Pharo-users] Pharo 5 hanging and crashing
> 
> Hi,
> 
> Pharo 5 is the current release, and you should use this one :).
> 
> Do you have a specific scenario that we can use to reproduce the crashing 
> behavior?
> 
> Cheers,
> Doru
> 
> 
>> On Jun 4, 2016, at 11:48 PM, Gerry Weaver  wrote:
>> 
>> Hello All,
>> 
>> I am new to Pharo and Smalltalk in general. I have been experimenting with 
>> Pharo 5 trying to get acquainted with the environment and the language. I 
>> have been having some issues with the image hanging and crashing. This 
>> happens when trying code in the Play Ground and especially when stepping 
>> through code in the debugger. Has anyone had similar problems? Should I be 
>> using Pharo 4 instead?
>> 
>> I have been testing Pharo on Windows 8 64bit and Ubuntu 14.04 64bit. Could 
>> this be a 64bit issue?
>> 
>> Thanks
> 
> --
> www.tudorgirba.com
> www.feenk.com
> 
> "What we can governs what we wish."
> 
> 
> 
> 
> 
> 

--
www.tudorgirba.com
www.feenk.com

"Innovation comes in the least expected form. 
That is, if it is expected, it already happened."

Re: [Pharo-users] problem getting moose

[Ben Coman]

On Sun, Jun 5, 2016 at 1:34 PM, Ben Coman  wrote:
> I wanted to try out Peter's XMI Analyser with Roassal and went to
> download Moose but had a couple of problems.
>
> First try...
> In the Launcher under Common Tools, I downloaded and Moose 5.1(stable)
> fine, but it is Pharo 4, so tried to download Moose 6.0(beta) -- but
> got a problem - big pause, no progress bars, the later ZipArchive
> reporting "Error: can't find EOCD position"
>
> Second try...
> The web site advises for Moose 6.0 to download the Moose code in a
> Pharo 5.0 image per...
>   Gofer new
>  smalltalkhubUser: 'Moose' project: 'Moose';
>  configuration;
>  loadDevelopment.
>
> Doing that in build 50760 download with the Launcher produced...
> Could not resolve: Phexample [Phexample-NikoSchwarz.57] in
> /home/ben/.local/share/Pharo/images/Moose6-50760/package-cache
> http://www.squeaksource.com/Moose ERROR: 'GoferRepositoryError: Could
> not access http://www.squeaksource.com/phexample: ZnInvalidUTF8:
> Illegal leading byte for utf-8 encoding'
>
> Could someone check if they see the same, or maybe my Internet is flakey atm?
> (preferably someone who doesn't normally use Moose to avoid package
> cache differences)

More info..

The repository defined in Monticello is
MCSqueaksourceRepository
location: 'http://www.squeaksource.com/phexample'
user: ''
password: ''
which I could not open, again getting...
  MCRepositoryError: Could not access
http://www.squeaksource.com/phexample: ZnInvalidUTF8: Illegal leading
byte for utf-8 encoding

I tried changing to...
   MCHttpRepository
   location: 'http://www.squeaksource.com/phexample'
   user: ''
   password: ''
with no luck.

But from Monticello I can define and successfully open another repository...
MCHttpRepository
location: 'http://www.squeaksource.com/DavidLightsOut'
user: ''
password: ''

The top of stack is...
"a MetacelloFetchingMCSpecLoader(atomic load : 4.4-beta.1 [ConfigurationOfMoose]
load : Filesystem-tg.85
load : Nile-Base-DamienCassou.81)"

btw,
Phexample-NikoSchwarz.57 (2010-10-26) seems quite old,
with the latest on Squeaksource being Phexample-NikoSchwarz.63.mcz2011-08-29;
latest on Smalltalkhub/PharoExtras/Phexample being
Phexample-Core-CamilloBruni.67 (05/03/2013);
latest on Smalltalk/Phexample/Phexample being
Phexample-DenisKudryashov.75 (08/04/2016)

cheers -ben

Re: [Pharo-users] problem getting moose

[Tudor Girba]

Hi,

> On Jun 5, 2016, at 7:34 AM, Ben Coman  wrote:
> 
> I wanted to try out Peter's XMI Analyser with Roassal and went to
> download Moose but had a couple of problems.
> 
> First try...
> In the Launcher under Common Tools, I downloaded and Moose 5.1(stable)
> fine, but it is Pharo 4, so tried to download Moose 6.0(beta) -- but
> got a problem - big pause, no progress bars, the later ZipArchive
> reporting "Error: can't find EOCD position”

You can download the image as well:
https://ci.inria.fr/moose/job/moose-6.0/lastSuccessfulBuild/artifact/moose-6.0.zip


> Second try...
> The web site advises for Moose 6.0 to download the Moose code in a
> Pharo 5.0 image per...
>  Gofer new
> smalltalkhubUser: 'Moose' project: 'Moose';
> configuration;
> loadDevelopment.

Indeed, this is what the CI job does.

> Doing that in build 50760 download with the Launcher produced...
> Could not resolve: Phexample [Phexample-NikoSchwarz.57] in
> /home/ben/.local/share/Pharo/images/Moose6-50760/package-cache
> http://www.squeaksource.com/Moose ERROR: 'GoferRepositoryError: Could
> not access http://www.squeaksource.com/phexample: ZnInvalidUTF8:
> Illegal leading byte for utf-8 encoding’

Strange. If you download the Moose image, you get the SmalltalkHub repo:
MCSmalltalkhubRepository
owner: 'Phexample'
project: 'Phexample'
user: ''
password: ''

> Could someone check if they see the same, or maybe my Internet is flakey atm?
> (preferably someone who doesn't normally use Moose to avoid package
> cache differences)

I am trying right now.

Doru

> cheers -ben
> 

--
www.tudorgirba.com
www.feenk.com

"Beauty is where we see it."

Re: [Pharo-users] problem getting moose

[Tudor Girba]

Hi,

I figured out the problem. When you run that script, you actually load 
"4.4-beta.1 [ConfigurationOfMoose]”

This is because of the mismatch between what loadDevelopment means in Gofer and 
the meaning of the symbolic version in Metacello.

Instead, please use this:

Metacello new
smalltalkhubUser: 'Moose' project: 'Moose';
configuration: 'Moose';
version: #development;
load.

I also updated the Moose webpage.

Cheers,
Doru


> On Jun 5, 2016, at 8:22 AM, Tudor Girba  wrote:
> 
> Hi,
> 
>> On Jun 5, 2016, at 7:34 AM, Ben Coman  wrote:
>> 
>> I wanted to try out Peter's XMI Analyser with Roassal and went to
>> download Moose but had a couple of problems.
>> 
>> First try...
>> In the Launcher under Common Tools, I downloaded and Moose 5.1(stable)
>> fine, but it is Pharo 4, so tried to download Moose 6.0(beta) -- but
>> got a problem - big pause, no progress bars, the later ZipArchive
>> reporting "Error: can't find EOCD position”
> 
> You can download the image as well:
> https://ci.inria.fr/moose/job/moose-6.0/lastSuccessfulBuild/artifact/moose-6.0.zip
> 
> 
>> Second try...
>> The web site advises for Moose 6.0 to download the Moose code in a
>> Pharo 5.0 image per...
>> Gofer new
>>smalltalkhubUser: 'Moose' project: 'Moose';
>>configuration;
>>loadDevelopment.
> 
> Indeed, this is what the CI job does.
> 
>> Doing that in build 50760 download with the Launcher produced...
>> Could not resolve: Phexample [Phexample-NikoSchwarz.57] in
>> /home/ben/.local/share/Pharo/images/Moose6-50760/package-cache
>> http://www.squeaksource.com/Moose ERROR: 'GoferRepositoryError: Could
>> not access http://www.squeaksource.com/phexample: ZnInvalidUTF8:
>> Illegal leading byte for utf-8 encoding’
> 
> Strange. If you download the Moose image, you get the SmalltalkHub repo:
> MCSmalltalkhubRepository
>   owner: 'Phexample'
>   project: 'Phexample'
>   user: ''
>   password: ''
> 
>> Could someone check if they see the same, or maybe my Internet is flakey atm?
>> (preferably someone who doesn't normally use Moose to avoid package
>> cache differences)
> 
> I am trying right now.
> 
> Doru
> 
>> cheers -ben
>> 
> 
> --
> www.tudorgirba.com
> www.feenk.com
> 
> "Beauty is where we see it."
> 
> 
> 
> 

--
www.tudorgirba.com
www.feenk.com

"Speaking louder won't make the point worthier."