[Pharo-users] Monthly Pharo Newsletter

2016-05-25 Thread marcus . denker
Hi,

Some time ago we set up a very low traffic “Pharo Newsletter” Mailinglist.

The idea is that this gets:
-> a mail for the release
-> *one* mail at the end of the month with 2-4 topics

It seems to work well. We have until now send two monty mails and the
mail for the Pharo5 release.


If you want to be on it, here is a link to subscribe:


http://pharo.us11.list-manage.com/subscribe?u=6f667565c2569234585a7be77&id=048680a940

If you follow all blogs, twitter + read all mails, there might not be anything 
new, but as things
get even hard to follow for me it might be a good way to keep up with the most 
important things
happening.

And: if you have an idea for content (e.g. highlighting a project or a success 
story), please get in
touch!

Marcus


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

2016-05-25 Thread Peter Uhnák
Hi,

yes, this question was raised before, but there are some disagreements over
how it should be, so it may take some time
http://forum.world.st/GTDebugger-shortcuts-usability-td4890316.html

You can also use a startup script to reassign them, such as this one.
https://github.com/peteruhnak/pharo-scripts/blob/master/config/5.0/uniformDebugger.st
But a startup script is a temporary solution.

On Wed, 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-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.
>
>


Re: [Pharo-users] Having a more robust PharoLauncher in low-bandwidth conditions

2016-05-25 Thread Peter Uhnák
> something like wget or curl

there's also zeroconf as the alternative, or directly downloading the zip
http://files.pharo.org/image/

Also Stef made a flash stick with Pharo, videos, etc. exactly for places
like this (with bad or no internet).

But of course PharoLauncher shouldn't crash. Alternatively PharoLauncher as
far as I know has a local cache, so maybe if you need just a fresh image
and not the latest one you could reuse that?

Peter

On Wed, May 25, 2016 at 6:37 PM, Serge Stinckwich <
serge.stinckw...@gmail.com> wrote:

> Dear all,
>
> in low-bandwidth countries, this is almost impossible to use
> PharoLauncher to dl new images from the CI. The problem is not really
> the speed (you just have to wait) but the robustness of the system.
> Most of the time, you PharoLauncher crash or you have an error like :
> "can't find EOCD position" before the end the of the download.
>
> I dunno exactly how PharoLauncher download images, but is it possible
> to think about a more robust way to dl images ? To be able to continue
> a dl if a network problem occurs (something like wget or curl) ?
>
> Thank you.
> --
> Serge Stinckwich
> UCBN & UMI UMMISCO 209 (IRD/UPMC)
> Every DSL ends up being Smalltalk
> http://www.doesnotunderstand.org/
>
>


Re: [Pharo-users] Problem with Mongo on Pharo5 ("collection already exists")

2016-05-25 Thread Sabine Manaa
Hi Esteban,

do you know a documentation/entry point about moving to github?
Is it in experimental state or recommended for all Pharo users?
How/where to start?

Regards
Sabine

2016-05-25 21:54 GMT+02:00 EstebanLM [via Smalltalk] <
ml-node+s1294792n489739...@n4.nabble.com>:

> Hi,
>
> yes, I recommend you to use the github version, we are moving there.
> But anyway we are keeping the sthub as mirror… it just got de-sync. And
> the only reason why I needed the merge, and not a simple copy is because
> metadataless format got activated and I lost the history, so I rather merge
> to recover history in some way… :)
>
> cheers!
> Esteban
>
> On 25 May 2016, at 21:23, Sabine Manaa <[hidden email]
> > wrote:
>
> Hi Esteban,
>
> great, now it works. Thank you!
>
> In the comments, I see "merged with github". I am curious about using
> github in future, too.
>
> Regards
> Sabine
>
> 2016-05-25 21:01 GMT+02:00 EstebanLM [via Smalltalk] < href="x-msg://138/user/SendEmail.jtp?type=node&node=4897384&i=0"
> target="_top" rel="nofollow" link="external" class="">[hidden email]>:
>
>> hi Sabine,
>>
>> please update to latest packages of Voyage… there was a de-sync problem
>> with the API change in MongoTalk, that *should* fix your issue.
>>
>> cheers,
>> Esteban
>>
>>
>> On 25 May 2016, at 16:29, Sabine Manaa <[hidden email]
>> > wrote:
>>
>> note that it only occurs (hanging image)  if you do
>> "VORepository current reset"
>> before. Or have a new Image.
>>
>>
>> 2016-05-25 15:38 GMT+02:00 Sabine Manaa <[hidden email]
>> >:
>>
>>> I have a non-responding image with the original code (with the signal)
>>>
>>> 2016-05-25 15:14 GMT+02:00 Holger Freyther [via Smalltalk] <[hidden
>>> email] >:
>>>

 > On 25 May 2016, at 15:42, Esteban Lorenzano <[hidden email]
 > wrote:
 >
 >

 Hi,


 > No I don’t… in part because is not me who make that code, but also
 because it is expected: after, you have:
 >
 > getCollection: aString
 > ^ [ self addCollection: aString capped: false size: nil max: nil ]
 > on: MongoCollectionAlreadyExists
 > do: [ :err |
 > MongoCollection database: self name: aString ]
 >
 > so the idea is to refine the error to separate
 MongoCollectionAlreadyExists so it can later be catch and handled properly.


 when adding capped collection support it seemed like a good idea to
 fail if a collection already exists that might not be capped, but given the
 follow up issues I wonder if I/we should restore the original behavior that
 just ignored all errors?

 holger


 --
 If you reply to this email, your message will be added to the
 discussion below:

 http://forum.world.st/Problem-with-Mongo-on-Pharo5-collection-already-exists-tp4897315p4897346.html
 To start a new topic under Pharo Smalltalk Users, email [hidden email]
 
 To unsubscribe from Pharo Smalltalk Users, click here.
 NAML
 

>>>
>>>
>>> --
>>> View this message in context: Re: Problem with Mongo on Pharo5
>>> ("collection already exists")
>>> 
>>>
>>> Sent from the Pharo Smalltalk Users mailing list archive
>>>  at
>>> Nabble.com .
>>>
>>
>>
>>
>>
>> --
>> If you reply to this email, your message will be added to the discussion
>> below:
>>
>> http://forum.world.st/Problem-with-Mongo-on-Pharo5-collection-already-exists-tp4897315p4897378.html
>> To start a new topic under Pharo Smalltalk Users, email > href="x-msg://138/user/SendEmail.jtp?type=node&node=4897384&i=1"
>> target="_top" rel="nofollow" link="external" class="">[hidden email]
>> To unsubscribe from Pharo Smalltalk Users, click here.
>> NAML
>> 
>>
>
>

Re: [Pharo-users] Problem with Mongo on Pharo5 ("collection already exists")

2016-05-25 Thread Esteban Lorenzano
Hi, 

yes, I recommend you to use the github version, we are moving there.
But anyway we are keeping the sthub as mirror… it just got de-sync. And the 
only reason why I needed the merge, and not a simple copy is because 
metadataless format got activated and I lost the history, so I rather merge to 
recover history in some way… :)

cheers!
Esteban

> On 25 May 2016, at 21:23, Sabine Manaa  wrote:
> 
> Hi Esteban,
> 
> great, now it works. Thank you!
> 
> In the comments, I see "merged with github". I am curious about using github 
> in future, too.
> 
> Regards 
> Sabine
> 
> 2016-05-25 21:01 GMT+02:00 EstebanLM [via Smalltalk] <[hidden email] 
> >:
> hi Sabine, 
> 
> please update to latest packages of Voyage… there was a de-sync problem with 
> the API change in MongoTalk, that *should* fix your issue. 
> 
> cheers, 
> Esteban
> 
> 
>> On 25 May 2016, at 16:29, Sabine Manaa <[hidden email] 
>> > wrote:
>> 
>> note that it only occurs (hanging image)  if you do
>> "VORepository current reset"
>> before. Or have a new Image.
>> 
>> 
>> 2016-05-25 15:38 GMT+02:00 Sabine Manaa <[hidden email] 
>> >:
>> I have a non-responding image with the original code (with the signal)
>> 
>> 2016-05-25 15:14 GMT+02:00 Holger Freyther [via Smalltalk] <[hidden email] 
>> >:
>> 
>> > On 25 May 2016, at 15:42, Esteban Lorenzano <[hidden email] 
>> > > wrote: 
>> > 
>> > 
>> 
>> Hi, 
>> 
>> 
>> > No I don’t… in part because is not me who make that code, but also because 
>> > it is expected: after, you have: 
>> > 
>> > getCollection: aString 
>> > ^ [ self addCollection: aString capped: false size: nil max: nil ] 
>> > on: MongoCollectionAlreadyExists 
>> > do: [ :err | 
>> > MongoCollection database: self name: aString ] 
>> > 
>> > so the idea is to refine the error to separate 
>> > MongoCollectionAlreadyExists so it can later be catch and handled 
>> > properly. 
>> 
>> when adding capped collection support it seemed like a good idea to fail if 
>> a collection already exists that might not be capped, but given the follow 
>> up issues I wonder if I/we should restore the original behavior that just 
>> ignored all errors? 
>> 
>> holger 
>> 
>> 
>> If you reply to this email, your message will be added to the discussion 
>> below:
>> http://forum.world.st/Problem-with-Mongo-on-Pharo5-collection-already-exists-tp4897315p4897346.html
>>  
>> 
>> To start a new topic under Pharo Smalltalk Users, email [hidden email] 
>>  
>> To unsubscribe from Pharo Smalltalk Users, click here <>.
>> NAML 
>> 
>> 
>> View this message in context: Re: Problem with Mongo on Pharo5 ("collection 
>> already exists") 
>> 
>> 
>> Sent from the Pharo Smalltalk Users mailing list archive 
>>  at Nabble.com 
>> .
>> 
> 
> 
> 
> If you reply to this email, your message will be added to the discussion 
> below:
> http://forum.world.st/Problem-with-Mongo-on-Pharo5-collection-already-exists-tp4897315p4897378.html
>  
> 
> To start a new topic under Pharo Smalltalk Users, email [hidden email] 
>  
> To unsubscribe from Pharo Smalltalk Users, click here 
> .
> NAML 
> 
> 
> View this message in context: Re: Problem with Mongo on Pharo5 ("collection 
> already exists") 
> 
> Sent from the Pharo Smalltalk Users mailing list archive 
>  at Nabble.com 
> .



[Pharo-users] One comment to new Pharo5 debugger

2016-05-25 Thread Sabine Manaa
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.



Re: [Pharo-users] Problem with Mongo on Pharo5 ("collection already exists")

2016-05-25 Thread Sabine Manaa
Hi Esteban,

great, now it works. Thank you!

In the comments, I see "merged with github". I am curious about using
github in future, too.

Regards
Sabine

2016-05-25 21:01 GMT+02:00 EstebanLM [via Smalltalk] <
ml-node+s1294792n4897378...@n4.nabble.com>:

> hi Sabine,
>
> please update to latest packages of Voyage… there was a de-sync problem
> with the API change in MongoTalk, that *should* fix your issue.
>
> cheers,
> Esteban
>
>
> On 25 May 2016, at 16:29, Sabine Manaa <[hidden email]
> > wrote:
>
> note that it only occurs (hanging image)  if you do
> "VORepository current reset"
> before. Or have a new Image.
>
>
> 2016-05-25 15:38 GMT+02:00 Sabine Manaa <[hidden email]
> >:
>
>> I have a non-responding image with the original code (with the signal)
>>
>> 2016-05-25 15:14 GMT+02:00 Holger Freyther [via Smalltalk] <[hidden
>> email] >:
>>
>>>
>>> > On 25 May 2016, at 15:42, Esteban Lorenzano <[hidden email]
>>> > wrote:
>>> >
>>> >
>>>
>>> Hi,
>>>
>>>
>>> > No I don’t… in part because is not me who make that code, but also
>>> because it is expected: after, you have:
>>> >
>>> > getCollection: aString
>>> > ^ [ self addCollection: aString capped: false size: nil max: nil ]
>>> > on: MongoCollectionAlreadyExists
>>> > do: [ :err |
>>> > MongoCollection database: self name: aString ]
>>> >
>>> > so the idea is to refine the error to separate
>>> MongoCollectionAlreadyExists so it can later be catch and handled properly.
>>>
>>> when adding capped collection support it seemed like a good idea to fail
>>> if a collection already exists that might not be capped, but given the
>>> follow up issues I wonder if I/we should restore the original behavior that
>>> just ignored all errors?
>>>
>>> holger
>>>
>>>
>>> --
>>> If you reply to this email, your message will be added to the discussion
>>> below:
>>>
>>> http://forum.world.st/Problem-with-Mongo-on-Pharo5-collection-already-exists-tp4897315p4897346.html
>>> To start a new topic under Pharo Smalltalk Users, email [hidden email]
>>> 
>>> To unsubscribe from Pharo Smalltalk Users, click here.
>>> NAML
>>> 
>>>
>>
>>
>> --
>> View this message in context: Re: Problem with Mongo on Pharo5
>> ("collection already exists")
>> 
>>
>> Sent from the Pharo Smalltalk Users mailing list archive
>>  at Nabble.com
>> .
>>
>
>
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://forum.world.st/Problem-with-Mongo-on-Pharo5-collection-already-exists-tp4897315p4897378.html
> To start a new topic under Pharo Smalltalk Users, email
> ml-node+s1294792n1310670...@n4.nabble.com
> To unsubscribe from Pharo Smalltalk Users, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://forum.world.st/Problem-with-Mongo-on-Pharo5-collection-already-exists-tp4897315p4897384.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Problem with Mongo on Pharo5 ("collection already exists")

2016-05-25 Thread Esteban Lorenzano
hi Sabine, 

please update to latest packages of Voyage… there was a de-sync problem with 
the API change in MongoTalk, that *should* fix your issue. 

cheers, 
Esteban


> On 25 May 2016, at 16:29, Sabine Manaa  wrote:
> 
> note that it only occurs (hanging image)  if you do
> "VORepository current reset"
> before. Or have a new Image.
> 
> 
> 2016-05-25 15:38 GMT+02:00 Sabine Manaa  >:
> I have a non-responding image with the original code (with the signal)
> 
> 2016-05-25 15:14 GMT+02:00 Holger Freyther [via Smalltalk] <[hidden email] 
> >:
> 
> > On 25 May 2016, at 15:42, Esteban Lorenzano <[hidden email] 
> > > wrote: 
> > 
> > 
> 
> Hi, 
> 
> 
> > No I don’t… in part because is not me who make that code, but also because 
> > it is expected: after, you have: 
> > 
> > getCollection: aString 
> > ^ [ self addCollection: aString capped: false size: nil max: nil ] 
> > on: MongoCollectionAlreadyExists 
> > do: [ :err | 
> > MongoCollection database: self name: aString ] 
> > 
> > so the idea is to refine the error to separate MongoCollectionAlreadyExists 
> > so it can later be catch and handled properly. 
> 
> when adding capped collection support it seemed like a good idea to fail if a 
> collection already exists that might not be capped, but given the follow up 
> issues I wonder if I/we should restore the original behavior that just 
> ignored all errors? 
> 
> holger 
> 
> 
> If you reply to this email, your message will be added to the discussion 
> below:
> http://forum.world.st/Problem-with-Mongo-on-Pharo5-collection-already-exists-tp4897315p4897346.html
>  
> 
> To start a new topic under Pharo Smalltalk Users, email [hidden email] 
>  
> To unsubscribe from Pharo Smalltalk Users, click here <>.
> NAML 
> 
> 
> View this message in context: Re: Problem with Mongo on Pharo5 ("collection 
> already exists") 
> 
> 
> Sent from the Pharo Smalltalk Users mailing list archive 
>  at Nabble.com.
> 



Re: [Pharo-users] Lockup when inspecting Text

2016-05-25 Thread Alistair Grant
On Wed, May 25, 2016 at 08:18:08PM +0200, Alistair Grant wrote:
> On Wed, May 25, 2016 at 07:08:53PM +0200, Alistair Grant wrote:
> > On Wed, May 25, 2016 at 04:08:49PM +, Henrik Nergaard wrote:
> > > Could you post the string/text object you have trouble inspecting?
> > > Both: "Text new inspect" and " (String loremIpsum: 1234) asText inspect" 
> > > works fine for me (Image 60035).
> > 
> > Inspecting the following will trigger the CPU loop:
> > 
> > 
> > | startPos aTextStream name |
> > 
> > aTextStream := TextStream on: (Text new: 1024).
> > name := 'silver | AB-com.cz'.
> > startPos := aTextStream position max: 1.
> > aTextStream
> > nextPutAll: name; 
> > applyAttribute: (TextFontReference toFont: (LogicalFont familyName: 
> > 'Source Sans Pro' pointSize: 20))
> > beginningAt: startPos;
> > cr; cr.
> > aTextStream contents.
> > 
> > (I thought it would take much longer to generate a small piece of code
> > that would reproduce the problem).
> 
> Actually, it is enough to have:
> 
> name := 'ABcom'
> 
> in the above.

And just learnt about kill -s SIGUSR1:


e/SIGUSR1 Wed May 25 20:53:48 2016
a

listai/home/alistair/pharo/pharo/pharo-vm/pharo
rpharo VM version: 5.0 #1 Wed May  4 11:54:28 CEST 2016 gcc 4.6.3
[Production Spur ITHB VM]
Built from: CoInterpreter VMMaker.oscog-eem.1855 uuid:
d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May  4 2016
With: StackToRegisterMappingCogit VMMaker.oscog-eem.1855 uuid:
d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May  4 2016
Revision: https://github.com/pharo-project/pharo-vm.git Commit:
b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22 +0200
By: Esteban Lorenzano  Jenkins build #589
Build host: Linux pharo-linux 3.2.0-31-generic-pae #50-Ubuntu SMP Fri
Sep 7 16:39:45 UTC 2012 i686 i686 i386 GNU/Linux
plugin path: /home/alistair/pharo/pharo/pharo-vm/ [default:
/home/alistair/pharo/pharo/pharo-vm/]
/

pC stack backtrace & registers:
ha  eax 0xff9c7164 ebx 0xff9c7080 ecx 0xff9c7118 edx 0xff9c70cc
ro  edi 0xff9c6f50 esi 0xff9c6f50 ebp 0xff9c6fe8 esp 0xff9c7034
/   eip 0xff9c7248
pharo*[0xff9c7248]
/home/alistair/pharo/pharo/pharo-vm/pharo[0x80c0912]
/home/alistair/pharo/pharo/pharo-vm/pharo[0x80c0bb9]
linux-gate.so.1(__kernel_rt_sigreturn+0x0)[0xf777ad30]
/home/alistair/pharo/pharo/pharo-vm/pharo(followForwardedObjectFieldstoDepth+0x38)[0x808f998]
/home/alistair/pharo/pharo/pharo-vm/pharo(followForwardedObjectFieldstoDepth+0xd8)[0x808fa38]
/home/alistair/pharo/pharo/pharo-vm/pharo(followForwardedObjectFieldstoDepth+0xd8)[0x808fa38]
/home/alistair/pharo/pharo/pharo-vm/pharo[0x808fd80]
[0x92a5ce3]
[0x92a5481]
[0x92b87b1]
[0x92af144]
[0x92aee8f]
[0x92d9820]
[0x92b9324]
[0x92a4fd7]
[0x9200b20]
[0xf7776848]


All Smalltalk process stacks (active first):
Process  0xcfe9d48 priority 40
0xff9d422c M
RubCompositionScanner(RubCharacterScanner)>scanCharactersFrom:to:in:rightX:stopConditions:kern:
0xde8cd90: a(n) RubCompositionScanner
0xff9d4264 M
RubCompositionScanner>composeFrom:inRectangle:firstLine:leftSide:rightSide:
0xde8cd90: a(n) RubCompositionScanner
0xff9d42a0 M RubTextComposer>composeEachRectangleIn: 0xde8ce18: a(n)
RubTextComposer
0xff9d42cc M RubTextComposer>composeAllRectangles: 0xde8ce18: a(n)
RubTextComposer
0xff9d42ec M RubTextComposer>composeOneLine 0xde8ce18: a(n)
RubTextComposer
0xff9d4304 M RubTextComposer>composeAllLines 0xde8ce18: a(n)
RubTextComposer
0xff9d431c M
RubTextComposer>composeLinesFrom:to:delta:into:priorLines:atY:textStyle:text:container:
0xde8ce18: a(n) RubTextComposer
0xff9d4358 M
RubTextComposer>composeLinesFrom:to:delta:into:priorLines:atY:
0xde8ce18: a(n) RubTextComposer
0xff9d20cc M [] in RubParagraph>compose 0xde8c328: a(n) RubParagraph
0xff9d20ec M BlockClosure>ensure: 0xc3e6600: a(n) BlockClosure
0xff9d2108 M RubParagraph>disableDrawingWhile: 0xde8c328: a(n)
RubParagraph
0xff9d2124 M RubParagraph>compose 0xde8c328: a(n) RubParagraph
0xff9d2144 M RubParagraph>extentFromClientBottomRight: 0xde8c328: a(n)
RubParagraph
0xff9d2160 M Message>sendTo: 0xc3e0d40: a(n) Message
0xff9d2180 M [] in
RubOpeningClosingDelimiterDecorator(RubParagraphDecorator)>doesNotUnderstand:
extentFromClientBottomRight: 0xde8c478: a(n)
RubOpeningClosingDelimiterDecorator
0xff9d2198 M BlockClosure>on:do: 0xc361248: a(n) BlockClosure
0xff9d21b8 M RubOpeningClosingDelimiterDecorator[I] [20:53:48]
alistair@alistair-xps13 (0) 
/home/alistair/pharo/pharo 
> (RubParagraphDecorator)>doesNotUnderstand:
> extentFromClientBottomRight: 0xde8c478: a(n)
> RubOpeningClosingDelimiterDecorator
0xff9d21d4 M Message>sendTo: 0xc32f378: a(n) Message
0xff9d21f4 M [] in
RubExtraSelectionDecorator(RubParagraphDecorator)>doesNotUnderstand:
extentFromClientBottomRight: 0xc32de50: a(n) RubExtraSelectionDecorator
0xff9d220c M BlockClosure>on:do: 0xc318948: a(n) BlockClosure
0xff9d222c M
RubExtraSelectionDecorator(RubParagraphDecorator)>doesNotUnderstand:
extentFromClientBottomRight: 0xc32de50: a(n) RubExtraSelectionDecorator
0

Re: [Pharo-users] Lockup when inspecting Text

2016-05-25 Thread Alistair Grant
On Wed, May 25, 2016 at 07:08:53PM +0200, Alistair Grant wrote:
> On Wed, May 25, 2016 at 04:08:49PM +, Henrik Nergaard wrote:
> > Could you post the string/text object you have trouble inspecting?
> > Both: "Text new inspect" and " (String loremIpsum: 1234) asText inspect" 
> > works fine for me (Image 60035).
> 
> Inspecting the following will trigger the CPU loop:
> 
> 
> | startPos aTextStream name |
> 
> aTextStream := TextStream on: (Text new: 1024).
> name := 'silver | AB-com.cz'.
> startPos := aTextStream position max: 1.
> aTextStream
>   nextPutAll: name; 
>   applyAttribute: (TextFontReference toFont: (LogicalFont familyName: 
> 'Source Sans Pro' pointSize: 20))
>   beginningAt: startPos;
>   cr; cr.
> aTextStream contents.
> 
> (I thought it would take much longer to generate a small piece of code
> that would reproduce the problem).

Actually, it is enough to have:

name := 'ABcom'

in the above.

Cheers,
Alistair




Re: [Pharo-users] Lockup when inspecting Text

2016-05-25 Thread Alistair Grant
On Wed, May 25, 2016 at 04:08:49PM +, Henrik Nergaard wrote:
> Could you post the string/text object you have trouble inspecting?
> Both: "Text new inspect" and " (String loremIpsum: 1234) asText inspect" 
> works fine for me (Image 60035).

Inspecting the following will trigger the CPU loop:


| startPos aTextStream name |

aTextStream := TextStream on: (Text new: 1024).
name := 'silver | AB-com.cz'.
startPos := aTextStream position max: 1.
aTextStream
nextPutAll: name; 
applyAttribute: (TextFontReference toFont: (LogicalFont familyName: 
'Source Sans Pro' pointSize: 20))
beginningAt: startPos;
cr; cr.
aTextStream contents.

(I thought it would take much longer to generate a small piece of code
that would reproduce the problem).


> 
>   I can't interrupt the display (Ctrl-.).
> Try (Alt-.)
> 
> Best regards,
> Henrik

Unfortunately Alt-. doesn't work either (both work when the system is
responsive).

Thanks!
Alistair



[Pharo-users] Having a more robust PharoLauncher in low-bandwidth conditions

2016-05-25 Thread Serge Stinckwich
Dear all,

in low-bandwidth countries, this is almost impossible to use
PharoLauncher to dl new images from the CI. The problem is not really
the speed (you just have to wait) but the robustness of the system.
Most of the time, you PharoLauncher crash or you have an error like :
"can't find EOCD position" before the end the of the download.

I dunno exactly how PharoLauncher download images, but is it possible
to think about a more robust way to dl images ? To be able to continue
a dl if a network problem occurs (something like wget or curl) ?

Thank you.
-- 
Serge Stinckwich
UCBN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
http://www.doesnotunderstand.org/



Re: [Pharo-users] Lockup when inspecting Text

2016-05-25 Thread Henrik Nergaard
Could you post the string/text object you have trouble inspecting?
Both: "Text new inspect" and " (String loremIpsum: 1234) asText inspect" works 
fine for me (Image 60035).

I can't interrupt the display (Ctrl-.).
Try (Alt-.)

Best regards,
Henrik

-Original Message-
From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of 
Alistair Grant
Sent: Wednesday, May 25, 2016 5:56 PM
To: pharo-users@lists.pharo.org
Subject: [Pharo-users] Lockup when inspecting Text

Hi All,

I've got a Text object which I can inspect the string or the runs, but when I 
attempt to inspect the text object itself Pharo goes into a CPU loop and 
becomes unresponsive.  I can't interrupt the display (Ctrl-.).

I've attempted to step through the code to find the problem, however Pharo is 
going into a CPU loop when returning from GLMMorphicPageRenderer>>render:.

I've included the stack trace leading to #render below.  At the moment I'm 
struggling for ideas on how to track this down.

Any suggestions?

Thanks!
Alistair


The stack trace just before returning from #render: is:

GLMMorphicPagerRenderer>>render:
GLMMorphicPagerRenderer class(GLMMorphicWidgetRenderer class)>>render:from:
GLMMorphicRenderer>>renderPager:
GLMPager>>renderGlamorouslyOn:
GLMMorphicRenderer(GLMRenderer)>>render:
GLMMorphicTabbedRenderer(GLMMorphicWidgetRenderer)>>renderObject:
GLMMorphicTabbedRenderer(GLMMorphicWidgetRenderer)>>renderWithTitleOrNil:
GLMMorphicTabbedRenderer>>render:
GLMMorphicTabbedRenderer class(GLMMorphicWidgetRenderer class)>>render:from:
GLMMorphicRenderer>>renderTabbedCompositePresentation:
GLMTabbedArrangement>>renderGlamorouslyOn:
GTInspector(GLMCompositePresentation)>>renderGlamorouslyOn:
GLMMorphicRenderer(GLMRenderer)>>render:
GLMMorphicWindowRenderer(GLMMorphicWidgetRenderer)>>renderObject:
GLMMorphicWindowRenderer>>render:
GLMMorphicWindowRenderer class(GLMMorphicWidgetRenderer
class)>>render:from:
GLMMorphicRenderer>>open:
GTInspector(GLMCompositePresentation)>>openWith:
GTInspector(GLMCompositePresentation)>>openOn:with:
GTInspector(GLMCompositePresentation)>>openOn:
GTInspector>>openOn:
GTInspector class>>openOn:
GTInspector class>>inspect:
Text(Object)>>inspect


This is where I'm attempting to inspect the object.


OrderedCollection>>DoIt
OpalCompiler>>evaluate
RubSmalltalkEditor>>evaluate:andDo:
RubSmalltalkEditor>>highlightEvaluateAndDo:
[ textMorph textArea editor highlightEvaluateAndDo: ann action.
textMorph shoutStyler style: textMorph text ] in [ textMorph textArea
handleEdit: [ textMorph textArea editor highlightEvaluateAndDo:
ann action.
textMorph shoutStyler style: textMorph text ] ] in
GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>>actOnHighlightAndEvaluate:
RubEditingArea(RubAbstractTextArea)>>handleEdit:
[ textMorph textArea
handleEdit: [ textMorph textArea editor highlightEvaluateAndDo:
ann action.
textMorph shoutStyler style: textMorph text ] ] in
GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>>actOnHighlightAndEvaluate:
WorldState>>runStepMethodsIn:
WorldMorph>>runStepMethods
WorldState>>doOneCycleNowFor:
WorldState>>doOneCycleFor:
WorldMorph>>doOneCycle
[ [ World doOneCycle.
Processor yield.
false ] whileFalse: [  ] ] in MorphicUIManager>>spawnNewProcess [ self value.
Processor terminateActive ] in BlockClosure>>newProcess





Re: [Pharo-users] Lockup when inspecting Text

2016-05-25 Thread Alistair Grant
On Wed, May 25, 2016 at 05:56:27PM +0200, Alistair Grant wrote:
> Hi All,
> 
> I've got a Text object which I can inspect the string or the runs, but
> when I attempt to inspect the text object itself Pharo goes into a CPU
> loop and becomes unresponsive.  I can't interrupt the display (Ctrl-.).
> 
> I've attempted to step through the code to find the problem, however
> Pharo is going into a CPU loop when returning
> from GLMMorphicPageRenderer>>render:.
> 
> I've included the stack trace leading to #render below.  At the moment
> I'm struggling for ideas on how to track this down.
> 
> Any suggestions?
> 
> Thanks!
> Alistair

P.S.:

Pharo5.0
Latest update: #50757

OS: 4.5.4-1-ARCH

> 
> 
> The stack trace just before returning from #render: is:
> 
> GLMMorphicPagerRenderer>>render:
> GLMMorphicPagerRenderer class(GLMMorphicWidgetRenderer class)>>render:from:
> GLMMorphicRenderer>>renderPager:
> GLMPager>>renderGlamorouslyOn:
> GLMMorphicRenderer(GLMRenderer)>>render:
> GLMMorphicTabbedRenderer(GLMMorphicWidgetRenderer)>>renderObject:
> GLMMorphicTabbedRenderer(GLMMorphicWidgetRenderer)>>renderWithTitleOrNil:
> GLMMorphicTabbedRenderer>>render:
> GLMMorphicTabbedRenderer class(GLMMorphicWidgetRenderer class)>>render:from:
> GLMMorphicRenderer>>renderTabbedCompositePresentation:
> GLMTabbedArrangement>>renderGlamorouslyOn:
> GTInspector(GLMCompositePresentation)>>renderGlamorouslyOn:
> GLMMorphicRenderer(GLMRenderer)>>render:
> GLMMorphicWindowRenderer(GLMMorphicWidgetRenderer)>>renderObject:
> GLMMorphicWindowRenderer>>render:
> GLMMorphicWindowRenderer class(GLMMorphicWidgetRenderer
> class)>>render:from:
> GLMMorphicRenderer>>open:
> GTInspector(GLMCompositePresentation)>>openWith:
> GTInspector(GLMCompositePresentation)>>openOn:with:
> GTInspector(GLMCompositePresentation)>>openOn:
> GTInspector>>openOn:
> GTInspector class>>openOn:
> GTInspector class>>inspect:
> Text(Object)>>inspect
> 
> 
> This is where I'm attempting to inspect the object.
> 
> 
> OrderedCollection>>DoIt
> OpalCompiler>>evaluate
> RubSmalltalkEditor>>evaluate:andDo:
> RubSmalltalkEditor>>highlightEvaluateAndDo:
> [ textMorph textArea editor highlightEvaluateAndDo: ann action.
> textMorph shoutStyler style: textMorph text ] in [ textMorph textArea
>   handleEdit: [ textMorph textArea editor highlightEvaluateAndDo:
> ann action.
>   textMorph shoutStyler style: textMorph text ] ] in
> GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>>actOnHighlightAndEvaluate:
> RubEditingArea(RubAbstractTextArea)>>handleEdit:
> [ textMorph textArea
>   handleEdit: [ textMorph textArea editor highlightEvaluateAndDo:
> ann action.
>   textMorph shoutStyler style: textMorph text ] ] in
> GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>>actOnHighlightAndEvaluate:
> WorldState>>runStepMethodsIn:
> WorldMorph>>runStepMethods
> WorldState>>doOneCycleNowFor:
> WorldState>>doOneCycleFor:
> WorldMorph>>doOneCycle
> [ [ World doOneCycle.
> Processor yield.
> false ] whileFalse: [  ] ] in MorphicUIManager>>spawnNewProcess
> [ self value.
> Processor terminateActive ] in BlockClosure>>newProcess
> 



[Pharo-users] Lockup when inspecting Text

2016-05-25 Thread Alistair Grant
Hi All,

I've got a Text object which I can inspect the string or the runs, but
when I attempt to inspect the text object itself Pharo goes into a CPU
loop and becomes unresponsive.  I can't interrupt the display (Ctrl-.).

I've attempted to step through the code to find the problem, however
Pharo is going into a CPU loop when returning
from GLMMorphicPageRenderer>>render:.

I've included the stack trace leading to #render below.  At the moment
I'm struggling for ideas on how to track this down.

Any suggestions?

Thanks!
Alistair


The stack trace just before returning from #render: is:

GLMMorphicPagerRenderer>>render:
GLMMorphicPagerRenderer class(GLMMorphicWidgetRenderer class)>>render:from:
GLMMorphicRenderer>>renderPager:
GLMPager>>renderGlamorouslyOn:
GLMMorphicRenderer(GLMRenderer)>>render:
GLMMorphicTabbedRenderer(GLMMorphicWidgetRenderer)>>renderObject:
GLMMorphicTabbedRenderer(GLMMorphicWidgetRenderer)>>renderWithTitleOrNil:
GLMMorphicTabbedRenderer>>render:
GLMMorphicTabbedRenderer class(GLMMorphicWidgetRenderer class)>>render:from:
GLMMorphicRenderer>>renderTabbedCompositePresentation:
GLMTabbedArrangement>>renderGlamorouslyOn:
GTInspector(GLMCompositePresentation)>>renderGlamorouslyOn:
GLMMorphicRenderer(GLMRenderer)>>render:
GLMMorphicWindowRenderer(GLMMorphicWidgetRenderer)>>renderObject:
GLMMorphicWindowRenderer>>render:
GLMMorphicWindowRenderer class(GLMMorphicWidgetRenderer
class)>>render:from:
GLMMorphicRenderer>>open:
GTInspector(GLMCompositePresentation)>>openWith:
GTInspector(GLMCompositePresentation)>>openOn:with:
GTInspector(GLMCompositePresentation)>>openOn:
GTInspector>>openOn:
GTInspector class>>openOn:
GTInspector class>>inspect:
Text(Object)>>inspect


This is where I'm attempting to inspect the object.


OrderedCollection>>DoIt
OpalCompiler>>evaluate
RubSmalltalkEditor>>evaluate:andDo:
RubSmalltalkEditor>>highlightEvaluateAndDo:
[ textMorph textArea editor highlightEvaluateAndDo: ann action.
textMorph shoutStyler style: textMorph text ] in [ textMorph textArea
handleEdit: [ textMorph textArea editor highlightEvaluateAndDo:
ann action.
textMorph shoutStyler style: textMorph text ] ] in
GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>>actOnHighlightAndEvaluate:
RubEditingArea(RubAbstractTextArea)>>handleEdit:
[ textMorph textArea
handleEdit: [ textMorph textArea editor highlightEvaluateAndDo:
ann action.
textMorph shoutStyler style: textMorph text ] ] in
GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>>actOnHighlightAndEvaluate:
WorldState>>runStepMethodsIn:
WorldMorph>>runStepMethods
WorldState>>doOneCycleNowFor:
WorldState>>doOneCycleFor:
WorldMorph>>doOneCycle
[ [ World doOneCycle.
Processor yield.
false ] whileFalse: [  ] ] in MorphicUIManager>>spawnNewProcess
[ self value.
Processor terminateActive ] in BlockClosure>>newProcess




Re: [Pharo-users] Problem with Mongo on Pharo5 ("collection already exists")

2016-05-25 Thread Sabine Manaa
note that it only occurs (hanging image)  if you do
"VORepository current reset"
before. Or have a new Image.


2016-05-25 15:38 GMT+02:00 Sabine Manaa :

> I have a non-responding image with the original code (with the signal)
>
> 2016-05-25 15:14 GMT+02:00 Holger Freyther [via Smalltalk] <[hidden email]
> >:
>
>>
>> > On 25 May 2016, at 15:42, Esteban Lorenzano <[hidden email]
>> > wrote:
>> >
>> >
>>
>> Hi,
>>
>>
>> > No I don’t… in part because is not me who make that code, but also
>> because it is expected: after, you have:
>> >
>> > getCollection: aString
>> > ^ [ self addCollection: aString capped: false size: nil max: nil ]
>> > on: MongoCollectionAlreadyExists
>> > do: [ :err |
>> > MongoCollection database: self name: aString ]
>> >
>> > so the idea is to refine the error to separate
>> MongoCollectionAlreadyExists so it can later be catch and handled properly.
>>
>> when adding capped collection support it seemed like a good idea to fail
>> if a collection already exists that might not be capped, but given the
>> follow up issues I wonder if I/we should restore the original behavior that
>> just ignored all errors?
>>
>> holger
>>
>>
>> --
>> If you reply to this email, your message will be added to the discussion
>> below:
>>
>> http://forum.world.st/Problem-with-Mongo-on-Pharo5-collection-already-exists-tp4897315p4897346.html
>> To start a new topic under Pharo Smalltalk Users, email [hidden email]
>> 
>> To unsubscribe from Pharo Smalltalk Users, click here.
>> NAML
>> 
>>
>
>
> --
> View this message in context: Re: Problem with Mongo on Pharo5
> ("collection already exists")
> 
>
> Sent from the Pharo Smalltalk Users mailing list archive
>  at Nabble.com.
>


Re: [Pharo-users] Problem with Mongo on Pharo5 ("collection already exists")

2016-05-25 Thread Sabine Manaa
I have a non-responding image with the original code (with the signal)

2016-05-25 15:14 GMT+02:00 Holger Freyther [via Smalltalk] <
ml-node+s1294792n4897346...@n4.nabble.com>:

>
> > On 25 May 2016, at 15:42, Esteban Lorenzano <[hidden email]
> > wrote:
> >
> >
>
> Hi,
>
>
> > No I don’t… in part because is not me who make that code, but also
> because it is expected: after, you have:
> >
> > getCollection: aString
> > ^ [ self addCollection: aString capped: false size: nil max: nil ]
> > on: MongoCollectionAlreadyExists
> > do: [ :err |
> > MongoCollection database: self name: aString ]
> >
> > so the idea is to refine the error to separate
> MongoCollectionAlreadyExists so it can later be catch and handled properly.
>
> when adding capped collection support it seemed like a good idea to fail
> if a collection already exists that might not be capped, but given the
> follow up issues I wonder if I/we should restore the original behavior that
> just ignored all errors?
>
> holger
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://forum.world.st/Problem-with-Mongo-on-Pharo5-collection-already-exists-tp4897315p4897346.html
> To start a new topic under Pharo Smalltalk Users, email
> ml-node+s1294792n1310670...@n4.nabble.com
> To unsubscribe from Pharo Smalltalk Users, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://forum.world.st/Problem-with-Mongo-on-Pharo5-collection-already-exists-tp4897315p4897348.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Problem with Mongo on Pharo5 ("collection already exists")

2016-05-25 Thread Holger Freyther

> On 25 May 2016, at 15:42, Esteban Lorenzano  wrote:
> 
> 

Hi,


> No I don’t… in part because is not me who make that code, but also because it 
> is expected: after, you have: 
> 
> getCollection: aString
>   ^ [ self addCollection: aString capped: false size: nil max: nil ]
>   on: MongoCollectionAlreadyExists 
>   do: [ :err | 
>   MongoCollection database: self name: aString ]
> 
> so the idea is to refine the error to separate MongoCollectionAlreadyExists 
> so it can later be catch and handled properly. 

when adding capped collection support it seemed like a good idea to fail if a 
collection already exists that might not be capped, but given the follow up 
issues I wonder if I/we should restore the original behavior that just ignored 
all errors?

holger


Re: [Pharo-users] Problem with Mongo on Pharo5 ("collection already exists")

2016-05-25 Thread Esteban Lorenzano

> On 25 May 2016, at 15:35, Sabine Manaa  wrote:
> 
> Hi Esteban,
> 
> can you please have a look again, I think you forgot to remove the signal here
>  (remove signal in the ifTrue case then it works):

No I don’t… in part because is not me who make that code, but also because it 
is expected: after, you have: 

getCollection: aString
^ [ self addCollection: aString capped: false size: nil max: nil ]
on: MongoCollectionAlreadyExists 
do: [ :err | 
MongoCollection database: self name: aString ]

so the idea is to refine the error to separate MongoCollectionAlreadyExists so 
it can later be catch and handled properly. 

cheers, 
Esteban

> 
> addCollection: aString capped: aCapped size: aSize max: aMax
>   | command |
>   command := SmallDictionary new.
>   command at: 'create' put: aString.
>   aCapped ifTrue: [
>   command at: 'capped' put: true.
>   aSize ifNotNil: [command at: 'size' put: aSize].
>   aMax ifNotNil: [command at: 'max' put: aMax]].
>   [ self command: command ]
>   on: MongoCommandError
>   do: [ :error |
>   "Tolerate error 48: collection already exists"
>   error isCollectionAlreadyExists
>   ==>>ifTrue: [ (MongoCollectionAlreadyExists new 
> collectionName: aString) "signal" ] <<==
>   ifFalse: [ error signal ] ].
>   ^MongoCollection database: self name: aString
> 
> 2016-05-25 12:59 GMT+02:00 Esteban Lorenzano  >:
> problem is not in Pharo 5 but in latest version of MongoTalk (who is loaded 
> with Pharo 5 and apparently not with Pharo 4).
> I already submitted a fix for it, but you need to load latest version (still 
> no configuration).
> 
> Esteban
> 
> > On 25 May 2016, at 12:18, Sabine Manaa  > > wrote:
> >
> > Hi,
> >
> > Is anyone already running Pharo5 with mongoDB already?
> >
> > loading my configurationOf in a new pharo5 image results in a problem with
> > mongDB.
> > loading the same in Pharo4 works fine.
> >
> > I reduced the problem to the following steps for reproduction:
> > 1) start Pharo5 and install VoyageMongo from the ProjectCatalog
> > 2) tools-> mongo Browser -> I see that I have connection to my database -ok
> > 3) (VOMongoRepository host: 'localhost' database: self databaseName)
> > enableSingleton.
> > 4) load ONLY my model classes which includes e.g. RKASystemMessage - load
> > nothing else
> > 5) Then I do  RKASystemMessage selectAll (there is ONE system message in the
> > mongo database) ==> this results in a non-responding image.
> > 6) when debugging into the selectAll, I see, that VoyageMongo tries to add a
> > collection (systemMessage), which is already there.
> >
> > in VOMongoRepositoryResolver>>collectionAt: aClass inDatabase: db
> > the collections attribute is empty -> this seems to be the problem
> > beause then it tries to do db addCollection: collectionName
> > which leads to a "collection already exists" mongo reply
> >
> > If you have a mongo database running, you should be able to reproduce the
> > problem.
> >
> > Regards
> > Sabine
> >
> >
> >
> >
> > --
> > View this message in context: 
> > http://forum.world.st/Problem-with-Mongo-on-Pharo5-collection-already-exists-tp4897315.html
> >  
> > 
> > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
> >
> 
> 
> 



Re: [Pharo-users] Problem with Mongo on Pharo5 ("collection already exists")

2016-05-25 Thread Sabine Manaa
Hi Esteban,

can you please have a look again, I think you forgot to remove the signal
here
 (remove signal in the ifTrue case then it works):

addCollection: aString capped: aCapped size: aSize max: aMax
| command |
command := SmallDictionary new.
command at: 'create' put: aString.
aCapped ifTrue: [
command at: 'capped' put: true.
aSize ifNotNil: [command at: 'size' put: aSize].
aMax ifNotNil: [command at: 'max' put: aMax]].
[ self command: command ]
on: MongoCommandError
do: [ :error |
"Tolerate error 48: collection already exists"
error isCollectionAlreadyExists
==>> ifTrue: [ (MongoCollectionAlreadyExists new collectionName: aString)
"signal" ] <<==
ifFalse: [ error signal ] ].
^MongoCollection database: self name: aString

2016-05-25 12:59 GMT+02:00 Esteban Lorenzano :

> problem is not in Pharo 5 but in latest version of MongoTalk (who is
> loaded with Pharo 5 and apparently not with Pharo 4).
> I already submitted a fix for it, but you need to load latest version
> (still no configuration).
>
> Esteban
>
> > On 25 May 2016, at 12:18, Sabine Manaa  wrote:
> >
> > Hi,
> >
> > Is anyone already running Pharo5 with mongoDB already?
> >
> > loading my configurationOf in a new pharo5 image results in a problem
> with
> > mongDB.
> > loading the same in Pharo4 works fine.
> >
> > I reduced the problem to the following steps for reproduction:
> > 1) start Pharo5 and install VoyageMongo from the ProjectCatalog
> > 2) tools-> mongo Browser -> I see that I have connection to my database
> -ok
> > 3) (VOMongoRepository host: 'localhost' database: self databaseName)
> > enableSingleton.
> > 4) load ONLY my model classes which includes e.g. RKASystemMessage - load
> > nothing else
> > 5) Then I do  RKASystemMessage selectAll (there is ONE system message in
> the
> > mongo database) ==> this results in a non-responding image.
> > 6) when debugging into the selectAll, I see, that VoyageMongo tries to
> add a
> > collection (systemMessage), which is already there.
> >
> > in VOMongoRepositoryResolver>>collectionAt: aClass inDatabase: db
> > the collections attribute is empty -> this seems to be the problem
> > beause then it tries to do db addCollection: collectionName
> > which leads to a "collection already exists" mongo reply
> >
> > If you have a mongo database running, you should be able to reproduce the
> > problem.
> >
> > Regards
> > Sabine
> >
> >
> >
> >
> > --
> > View this message in context:
> http://forum.world.st/Problem-with-Mongo-on-Pharo5-collection-already-exists-tp4897315.html
> > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
> >
>
>
>


Re: [Pharo-users] Problem with Mongo on Pharo5 ("collection already exists")

2016-05-25 Thread Esteban Lorenzano
problem is not in Pharo 5 but in latest version of MongoTalk (who is loaded 
with Pharo 5 and apparently not with Pharo 4). 
I already submitted a fix for it, but you need to load latest version (still no 
configuration).

Esteban

> On 25 May 2016, at 12:18, Sabine Manaa  wrote:
> 
> Hi,
> 
> Is anyone already running Pharo5 with mongoDB already?
> 
> loading my configurationOf in a new pharo5 image results in a problem with
> mongDB.
> loading the same in Pharo4 works fine.
> 
> I reduced the problem to the following steps for reproduction:
> 1) start Pharo5 and install VoyageMongo from the ProjectCatalog
> 2) tools-> mongo Browser -> I see that I have connection to my database -ok
> 3) (VOMongoRepository host: 'localhost' database: self databaseName)
> enableSingleton.
> 4) load ONLY my model classes which includes e.g. RKASystemMessage - load
> nothing else
> 5) Then I do  RKASystemMessage selectAll (there is ONE system message in the
> mongo database) ==> this results in a non-responding image.
> 6) when debugging into the selectAll, I see, that VoyageMongo tries to add a
> collection (systemMessage), which is already there. 
> 
> in VOMongoRepositoryResolver>>collectionAt: aClass inDatabase: db
> the collections attribute is empty -> this seems to be the problem
> beause then it tries to do db addCollection: collectionName 
> which leads to a "collection already exists" mongo reply
> 
> If you have a mongo database running, you should be able to reproduce the
> problem.
> 
> Regards
> Sabine
>
> 
> 
> 
> --
> View this message in context: 
> http://forum.world.st/Problem-with-Mongo-on-Pharo5-collection-already-exists-tp4897315.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
> 




[Pharo-users] Problem with Mongo on Pharo5 ("collection already exists")

2016-05-25 Thread Sabine Manaa
Hi,

Is anyone already running Pharo5 with mongoDB already?

loading my configurationOf in a new pharo5 image results in a problem with
mongDB.
loading the same in Pharo4 works fine.

I reduced the problem to the following steps for reproduction:
1) start Pharo5 and install VoyageMongo from the ProjectCatalog
2) tools-> mongo Browser -> I see that I have connection to my database -ok
3) (VOMongoRepository host: 'localhost' database: self databaseName)
enableSingleton.
4) load ONLY my model classes which includes e.g. RKASystemMessage - load
nothing else
5) Then I do  RKASystemMessage selectAll (there is ONE system message in the
mongo database) ==> this results in a non-responding image.
6) when debugging into the selectAll, I see, that VoyageMongo tries to add a
collection (systemMessage), which is already there. 

in VOMongoRepositoryResolver>>collectionAt: aClass inDatabase: db
the collections attribute is empty -> this seems to be the problem
beause then it tries to do db addCollection: collectionName 
which leads to a "collection already exists" mongo reply

If you have a mongo database running, you should be able to reproduce the
problem.

Regards
Sabine
 



--
View this message in context: 
http://forum.world.st/Problem-with-Mongo-on-Pharo5-collection-already-exists-tp4897315.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.



Re: [Pharo-users] An Idea for a minimal self documented begineer friendly pharo image

2016-05-25 Thread Dimitris Chloupis
there is intersection afterall interactive documentation is the holy grail
of documentation. I would love to have that. I was thinking making my
Prometheas project not just a a bunch of pillar files but also an internal
tool inside pharo that can show you titles of chapters of documentation
which will link to the htmls produced by pillar in several books and open a
web browser so the pharo users seens the very latest of documentation in a
application he is very familiar with web browser. That should be easy
enough to do.

Your approach and tools can play the role of interactive tutorials , like
ProfStef but of course with far more flexibility. So I would love to be
kept up to date to your progress and I am definetly very interested. Thank
you for bringing this to my attention I will definetly include it in
Prometheus.

On Wed, May 25, 2016 at 12:16 AM Offray Vladimir Luna Cárdenas <
offray.l...@mutabit.com> wrote:

> Hi,
>
> Nice to see this efforts.
>
> I will try to help with my interactive notebook documentation project for
> reproducible/open research and by making visualization for more diverse
> fields, mainly data activism: Panama Papers[1], Political
> discourses[2](should be updated), but also medicines [3]. Also I'm making
> some builders to make more easy specific domain visualizations and
> re-reading, this time deeply, the Agile Visualization book and making some
> comments (i.e [4][5])
>
> [1] http://mutabit.com/offray/blog/en/entry/panama-papers-1
> [2]
> http://mutabit.com/offray/static/blog/output/posts/visualizing-politicianspolitical-discourses-on-twitter.html
> [3] http://mutabit.com/offray/blog/en/entry/sdv-infomed
> [4]
> https://hyp.is/8hHnlCHzEeaIfiOOWSL11w/dl.dropboxusercontent.com/u/31543901/AgileVisualization/QuickStart/0101-QuickStart.html
> [5]
> https://hyp.is/44eZbiHxEeaykduI7FzoXQ/dl.dropboxusercontent.com/u/31543901/AgileVisualization/QuickStart/0101-QuickStart.html
>
> I just tell this because at some point could be an
> intersection/complementarity from the documentation point and helps to have
> this overview of where people is focused and trying to contribute. I don't
> know if there is a place where interested can find where other people is
> doing that is not properly software (or is not integrated yet into
> software)... kind of related project/interest in Pharo.
>
> Cheers,
>
> Offray
>
>
> On 24/05/16 15:55, Dimitris Chloupis wrote:
>
> WOW I did not expect so many replies
>
> Its amazing you guys work on a minimal image, since that is the case I
> will wait for you experts to deliver and instead as you advise me Esteban I
> will focus my effort on documentation, it looks like I have come to a
> decision to contribute to pharo in 3 ways
>
> 1) Make a theme for pharo which is very modern flexible and super easy to
> customise to whatever one wants, a theme to rule them all -> Nireas (its
> there but needs a lot of improvement)
> 2) Make an API for Blender that will allow pharo developers to take
> advantage of Blender awesome graphics capabilities -> Ephestos (same as
> above)
> 3) Contribute to documentation both via pillar and class and method
> comments. -> Prometheas (same as above)
>
> I am sure the minimal image that you will provide will be perfect for my
> needs. I dont mind size per se, just system complexity.
>
> I agree again with you Esteban that it would be better to let the
> maintaince of a minimal image to pharo devs since I think we are all in the
> same page and instead tackle areas of my expertise like graphics, theme and
> documentation.
>
> I was just thinking how I could help Pharo the best way and I think these
> 3 projects are more than enough to keep me occupied.
>
> The linked image you posted does not open after I download it and unzip
> it. Does it require a special VM or is it something else ?
>
> On Tue, May 24, 2016 at 5:28 PM Thierry Goubier 
> wrote:
>
>> 2016-05-24 16:18 GMT+02:00 Esteban Lorenzano :
>>
>>>
>>> On 24 May 2016, at 16:11, Thierry Goubier 
>>> wrote:
>>>
>>>
>>>
>>> 2016-05-24 15:18 GMT+02:00 Dimitris Chloupis :
>>>
 Well technically the python part works fine, BUT I also always wanted
 it to be friendly to begineers . So nope , its same project. And you are
 correct its still focused in coding 3d graphics but I came to realisation
 that if I want some people to use it, obviously i dont expect the massive
 majority to give up the comforts of python but for those that are curious I
 have to provide an enviroment thats is even easier to code in than python
 is currently for Blender.

 My goal is to provide a development enviroment for Blender addons that
 is simple, and easy to use and learn.

 So providing a minimal pharo image that is self documented has always
 being a dream for Ephestos.

 By the way whats the news on the matter of modular pharo image ? Is
 there any work done to provide a minimal pharo image ?

>>>
>>> There is a minimal image, whic

[Pharo-users] FileSystem Symlink and Environment variables

2016-05-25 Thread Valentin Ryckewaert
Hello everyone,

I would like to know more about what lacks to FileSystem today ?
Especially for symbolic links, I didn't find something to read the real
path of the symlink (readlink) and to create a symbolic link, does it
exists and I didn't find it?
I tried to use isSymlink on my machine (linux one) and it didn't work, we
submited an issue but does someone know the problem ?
https://pharo.fogbugz.com/f/cases/18279/isSymlink-seems-to-be-broken-on-Linux

Same thing for Environment variables, I would like to know if the
implementation lacks of something usefull.

Valentin


Re: [Pharo-users] parameters of the virtual machine

2016-05-25 Thread Clément Bera
Well the aspects described here either are documented or are being
documented through IWST papers waiting for approval.

The cache accessing technique is detailed in the IWST'16 paper *Inferring
Types by Mining Class Usage Frequency from Inline Caches**. *Hopefully
it'll get accepted and everyone can read it. Nevena worked a lot on it and
I believe it's very good.

The VM parameters are detailed in Pharo in the method comment of
VirtualMachine>>parameterAt: . The comment is self-explanatory so if one
does not understand it one needs to read already available documentation
about the VM internal behavior.

The machine code zone details I added are discussed in my IWST'16 paper *A
low Overhead Per Object Write Barrier for Smalltalk. *Hopefully it'll get
accepted and everyone can read it.

On Wed, May 25, 2016 at 8:46 AM, stepharo  wrote:

> clement
>
>
> you should add that to a simple blog post :)
>
>
> Stef
>
> Le 24/5/16 à 19:35, Clément Bera a écrit :
>
> Hi,
>
> Sorry the mail is quite long... I CC'd Nevena for section II, she used the
> VM caches for type inference.
>
> *Section I. VM parameters*
>
> *  46  size of machine code zone, in bytes*
>
> Well, the size of the machine code zone :-). To speed-up execution, the
> cog uses internally a JIT compiler which translates to machine code
> frequently used bytecoded method and run the machine code to execute them
> instead of using the interpreter. The machine code zone is an executable
> memory zone containing all the machine code versions of methods.
>
> The default size should be between 1Mb and 2Mb for standard applications.
> If memory is a constraint, it can be lowered down to 750kb, under that you
> should use the stack VM else the performance starts to drastically decrease.
>
> This setting is useful to tune your application performance. For example,
> on compilation-intensive benchs, 750kb is the optimal machine code zone
> size. On large benchmarks, 2 Mb, maybe more, is better, but then one may
> see machine code garbage collection pauses. On small benchs all the methods
> fit into this zone so it doesn't really matter.
>
> Growing the machine code zone:
> - increase the number of methods that can be present there, hence
> decreasing machine code zone garbage collection frequency and method jit
> compilation.
> - decrease the machine code zone to cpu instruction cache mapping
> - slow down machine code zone garbage collection
>
> To set the machine code zone you need to use another parameter (47 I
> think) and restart the VM+image.
>
> *  59  number of check event calls since startup (read-only)*
>
> If I remember correctly, the number of times the VM has checked for OS
> events since start-up.
>
>
> * 60  number of stack page overflows since startup (read-only; Cog VMs
> only)  61  number of stack page divorces since startup (read-only; Cog
> VMs only)*
>
> This is related to stack page management. Read the Cog blog to understand
> how it's done. See
> 
> http://www.mirandabanda.org/cogblog/2009/01/14/under-cover-contexts-and-the-big-frame-up/
> section Stack pages.
>
> *Section II. Accessing the caches*
>
>
>
>
> *Is there a way to get access to the cache? How many caches does Cog has?
> I guess it has - a method call cache (associating (object,symbol)
> -> compiled method - a cache for the JIT-compiled methods right? *
>
>
> *Are there other cache? How can I access them? In particular to query
> about their fill. *
>
> There is indeed a global look-up cache, mapping (receiver type, symbol) ->
> (compiled method, primitive function pointer). In the jitted methods there
> are per send-sites look-up caches, also known as inline caches.
>
> The most useful is the inline cache values, they provide the receiver
> types met for each send site and are fairly reliable. There are ways to
> access those caches. I personally use those caches values for the runtime
> optimizing compiler, but more recently I worked with Nevena Milojkovic (I
> CC'd her) and she was able to use those cache values for type inference,
> while she is not a VM expert. We wrote an IWST paper about that, hopefully
> it'll get accepted and you will be able to read it. In the IWST paper I
> sum-up Eliot's implementation of inline caches and how the VM provides the
> types.
>
> In short, to access the caches:
> 1) add those primitives:
> VirtualMachine>>allMachineCodeMethods
>
>^#()
> CompiledMethod>>sendAndBranchData
>
>^#()
> 2) add glue code to map caches values from bytecode pc to the AST,
> something like that:
> CompiledMethod>>astWithCacheAnnotations
> | tmp1 |
> tmp1 := self sendAndBranchData.
> tmp1
> ifEmpty: [ 'No data' logCr.
> ^ self ast ];
> do: [ :arg1 |
> (self sourceNodeForPC: arg1 first)
> propertyAt: #cacheInformation
> put: arg1 allButFirst ].
> ^ self ast
> 3) Compile the VM with the SistaCogit and SistaVM=true (Slang comp