Re: [Pharo-dev] Issue 12970 - 16 steps to get through #halt - PROPOSED FIX

[Eliot Miranda]

On Fri, Jan 30, 2015 at 2:54 PM, Sean P. DeNigris 
wrote:

> Ben Coman wrote
> > @Sean,  In what way will it make halts more annoying?
>
> Clearly seems to make things better in your use case, but IIRC the purpose
> of that test is that you don't want to open the debugger within the halting
> system. And indeed, when you remove it, you end up in #halt. But where you
> want to be is in UndefinedObject>>DoIt. So, it seems like a hack that,
> while
> better in this case, may have implications in other cases. The solution
> we're looking for is: "debuggers-opened-due-to-halts always open on the
> first context totally outside the halt machinery" and we're not quite there
> yet.
>

Nobody responded to my suggestion of inlining the code for haltOnce so that
the Halt signal happens in haltOnce itself, just as it does inside halt.
This may make the system respond to haltOnce the same as it does to halt.
 i.e. the debugger can look to the sender of the signalling context.  As it
is now, the sender of the signalling context of a haltOnce is halt, not the
sender of haltOnce as desired.


Let me reiterate, I expect

haltOnce
"Halt unless we have already done it once."
(Smalltalk at: #HaltOnce ifAbsent: [false]) ifTrue:
[Smalltalk at: #HaltOnce put: false.
Halt signal]

will behave similarly to

halt
Halt signal

and stop the debugger where desired. If the decomposition into
haltOnceEnabled & clearHaltOnce is desired it can still be written


haltOnce
"Halt unless we have already done it once."
self haltOnceEnabled ifTrue:
[self clearHaltOnce.
Halt signal]

but keeping Halt signal in haltOnce instead of invoking through halt is key.


> -
> Cheers,
> Sean
> --
> View this message in context:
> http://forum.world.st/Issue-12970-16-steps-to-get-through-halt-PROPOSED-FIX-tp4801405p4802841.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>


-- 
best,
Eliot

Re: [Pharo-dev] Issue 12970 - 16 steps to get through #halt - PROPOSED FIX

[Sean P. DeNigris]

Ben Coman wrote
> @Sean,  In what way will it make halts more annoying?

Clearly seems to make things better in your use case, but IIRC the purpose
of that test is that you don't want to open the debugger within the halting
system. And indeed, when you remove it, you end up in #halt. But where you
want to be is in UndefinedObject>>DoIt. So, it seems like a hack that, while
better in this case, may have implications in other cases. The solution
we're looking for is: "debuggers-opened-due-to-halts always open on the
first context totally outside the halt machinery" and we're not quite there
yet.



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Issue-12970-16-steps-to-get-through-halt-PROPOSED-FIX-tp4801405p4802841.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Fwd: 14827 ProtoObject>>pointersTo failing circular references

[Eliot Miranda]

On Fri, Jan 30, 2015 at 6:32 AM, Ben Coman  wrote:

> Yes. I just got back to looking at it and noticed the culprit was
> printString.  Now  #printString --> #printStringLimitedTo: -->
> #streamContents:limitedTo:  which uses LimitedWriteStream that should
> protect against such recursion.
>
> However  Array>>printOn:  is...
>
> self shouldBePrintedAsLiteral ifTrue: [self printAsLiteralFormOn: aStream.
> ^ self].
> self isSelfEvaluating ifTrue: [self printAsSelfEvaluatingFormOn: aStream.
> ^ self].
> super printOn: aStream
>
> where  #shouldBePrintedAsLiteral  and  #isSelfEvaluating recursively call
> themselves - bypassing the protection of LimitedWriteStream.
>
> As an aside,   Array>>shouldBePrintedAsLiteral  seems identical to
>  Array>>isLiteral  -- so is it redundant and the former be deprecated?
>
> Now I don't quite follow the semantics of #isLiteral and #isSelfEvaluating
> for Arrays.
>
> a := #( 1 2 { 3 . 4 } 5).
> a isLiteral. "true"
> a isSelfEvaluating. "true"
>
> b := { 1 . 2 . #( 3 4 ) . 5 }.
> b isLiteral. "true"
> b isSelfEvaluating. "true"
>
> So can someone provide an example for an Array where  #isLiteral  or
>  #isSelfEvaluating   are false ?  Otherwise it seems it will always take
> the first condition of Array>>printOn: .
>

An Array that contains anything that isn't literal.  e.g.

{1@2}

{1@2} isLiteral => false

{{1@2} size. #(1@2) size} => #(1 3)


> cheers -ben
>
> On Fri, Jan 30, 2015 at 9:23 PM, Nicolai Hess  wrote:
>
>> Quick and Dirty,
>> replace Array>>#printOn:
>> with
>>
>> printOn: aStream
>> self class = Array ifTrue: [self printAsSelfEvaluatingFormOn:
>> aStream. ^ self].
>> super printOn: aStream
>>
>> testObject := 'TEST'.
>> ref1 := { testObject. nil }.
>> ref2 := { ref1 }.
>> ref3 := { ref2 }.
>> ref1 at: 2 put: ref3.  "note the reference loop this creates"
>> testObject pointersTo asString
>>
>> works
>>
>>
>> 2015-01-30 14:15 GMT+01:00 Nicolai Hess :
>>
>>> Hi Ben,
>>>
>>> i don't know exactly what is happening here, but (size vs. inpsect)
>>>
>>> testObject := 'TEST'.
>>> ref1 := { testObject. nil }.
>>> ref2 := { ref1 }.
>>> ref3 := { ref2 }.
>>> ref1 at: 2 put: ref3.  "note the reference loop this creates"
>>> testObject pointersTo size
>>> -> 5
>>>
>>>
>>>
>>> works. So, the problem is not in #pointersTo but inspecting the result
>>> array has one or more recursive self calls
>>> to its elements.
>>>
>>>
>>>
>>>
>>> 2015-01-30 3:59 GMT+01:00 Ben Coman :
>>>

 I am revisiting my PointerDetective tool, which relies heavily on
 ProtoObject>>pointersTo.

 The example I recorded at the repository home page is currently locking
 & crashing the image due to #pointersTo being unable to handle the circular
 reference.  This "must" have been working on Windows at least around August
 2014, but I've been unable to reproduce a working case since my Windows
 laptop died and I've since moved to OSX.

 On OSX, in a fresh image 40467 and latest vm 402, the following crashes
 the image...

 testObject := 'TEST'.
 ref1 := { testObject. nil }.
 ref2 := { ref1 }.
 ref3 := { ref2 }.
 ref1 at: 2 put: ref3.  "note the reference loop this creates"
 testObject pointersTo inspect.

 OSX Memory Monitor shows memory usage shoot from 50MB to >500MB in a
 few seconds, then usually the image crashes, but sometimes just hangs.

 I've logged...
 https://pharo.fogbugz.com/default.asp?14827

 cheers -ben


>>>
>>
>


-- 
best,
Eliot

Re: [Pharo-dev] Tools for automatic recognition of Design Patterns

[Atlas]

Sounds exciting, I'd be also happy to know if there is any tool I might have
missed.

You might want to take a look at the ASTInterpreter and write the analyses
yourselves, if that is an option.  As a matter of fact, I have some
experience in doing program analysis and design pattern detection, but
that's a long time ago. If you need any help, please let me know.





--
View this message in context: 
http://forum.world.st/Tools-for-automatic-recognition-of-Design-Patterns-tp4802777p4802793.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Tools for automatic recognition of Design Patterns

[Richard Sargent]

Nevena Milojkovic wrote
> Can anyone suggest me tool for automatic design patterns detection in
> Smalltalk?

The rewrite tool in the Refactoring Browser has the potential, but I
strongly suspect the problem is intractable.

By the way, the rewrite tool is powerful but difficult to figure out and
use, even when you can find the documentation for it.




--
View this message in context: 
http://forum.world.st/Tools-for-automatic-recognition-of-Design-Patterns-tp4802777p4802789.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Create window group for Playground

[Torsten Bergmann]

Hi Doru,

>You are now talking about exactly one item out of 10. When was the last time 
>you used the 
>Close menu entry from that menu?

As I said in my mail - I'm more keen on getting the feature back than
getting back this menu. 

>If we do not go through this process we will find out in 10 years that we have 
>the same 
>solutions around us. I know it can be painful but the investment is worth it.

Will "we be better" when we remove a windows menu because we usually use 
keyboard shortcuts to close windows? I doubt it. Where do you want to put
the info what can be done with the window?

Look at all the regular computer window based UI system: they still have such a 
menu. Will we really break with these expectations?

For sure we could slim down and reduce it because we do not like it. But in 
regular OS systems
these contain textual menu infos what you can do and to my knowledge this is 
also used 
by accessibility tools like screen readers, ...
 
>Well. It is hard to come with new things by doing exactly the same things as 
>yesterday.

Agree with that - but other window manager designers where not too bad in 
thinking
about such issues. 
 
>So, that means that you do prefer the Playground after all :)

Yes. Do do not misunderstand my posts. I enjoy these new tools - still I ask you
questions like "why do I click on Workspace and get a Playground" or "why is 
grouping not possible anymore"? 
To me the first one is simply not intuitive and the other one a break in my 
flow. 

>That might be a solution, but what we have now is not such a solution. 
>Please give us time.

Yes - maybe we must be more patient. I understand that sometimes one has to 
go 1 step backward to move 2 steps forward :)

Bye
T.

[Pharo-dev] Tools for automatic recognition of Design Patterns

[Nevena Milojkovic]

Hi,

Can anyone suggest me tool for automatic design patterns detection in Smalltalk?

Cheers,
Nevena Milojkovic 



Nevena Milojkovic
Research assistant
Software Composition Group 
Institute of Computer Science and Applied Mathematics 
University of Bern 

email: nev...@iam.unibe.ch 
office phone: +41 (0)31 511 7639  
webpage: http://scg.unibe.ch/staff/Milojkovic 

Re: [Pharo-dev] Create window group for Playground

[Ben Coman]

On Fri, Jan 30, 2015 at 11:06 PM, Tudor Girba  wrote:

> Hi,
>
> On Fri, Jan 30, 2015 at 3:06 PM, Torsten Bergmann  wrote:
>
>> >Peter Uhnák
>> >It's still a regular window, so it's possible, the only difference is
>> missing button for it, which according to Tudor was removed purposefully.
>> >
>> >
>> http://forum.world.st/GT-Playground-Inspect-window-menu-tp4782020p4782044.html
>>
>> Looks like I missed this thread. Tudor comment is a little bit funny
>> there: "by default in Morphic every window gets the generic menu that
>> nobody really uses,". When he does not use it it does not mean that all
>> other do not use it ;)
>>
>
> You are now talking about exactly one item out of 10. When was the last
> time you used the Close menu entry from that menu?
> If we do not go through this process we will find out in 10 years that we
> have the same solutions around us. I know it can be painful but the
> investment is worth it.
>
>
>
I agree with that philosophy. Now btw, one menu item I do miss is "Make
uncloseable".  This make it easier/safer to clean up using "Windows >
Delete all windows discarding edits" **.  Perhaps that could become a pin
icon next the to normal three min/max/close icons in the top left?

**though the Plague Doctor might be interesting to try

cheers -ben

Re: [Pharo-dev] Create window group for Playground

[Atlas]

Funny, I didn't know about that feature either. Thanks for the informative
video, kilon.


> The issue of many windows is a significant problem that deserves a closer
> attention.

Well, for starters, I am wondering why the World Window is limited to my
screen size (or have I missed something?).
I think it would make a better experience if the main window was infinite in
size just like in the  Self Environment   .
This way I could put windows, workspaces and other artifacts to locations
that have specific meanings to me (spatial memory, very important), just
like you would organize any working place. This would work great with a
seemless zoom function.

 

In addition, it might be helpful to have multiple world windows and to be
able to arrange them, just like in  Xmonad   .

Unfortuantely, I do not have the resources to implement that but I think
that these changes would be very beneficial. For a start, it would be great
to have a zoomable infinite workspace.







--
View this message in context: 
http://forum.world.st/Create-window-group-for-Playground-tp4802517p4802751.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Create window group for Playground

[Tudor Girba]

Hi,

On Fri, Jan 30, 2015 at 3:06 PM, Torsten Bergmann  wrote:

> >Peter Uhnák
> >It's still a regular window, so it's possible, the only difference is
> missing button for it, which according to Tudor was removed purposefully.
> >
> >
> http://forum.world.st/GT-Playground-Inspect-window-menu-tp4782020p4782044.html
>
> Looks like I missed this thread. Tudor comment is a little bit funny
> there: "by default in Morphic every window gets the generic menu that
> nobody really uses,". When he does not use it it does not mean that all
> other do not use it ;)
>

You are now talking about exactly one item out of 10. When was the last
time you used the Close menu entry from that menu?
If we do not go through this process we will find out in 10 years that we
have the same solutions around us. I know it can be painful but the
investment is worth it.


I like when we make progress - but we should also take care not to
> constantly break others flow.
>

Well. It is hard to come with new things by doing exactly the same things
as yesterday.



> I also currently circumvent the missing functionality the same way as
> Kilon describes: by opening an old workspace first,
> switching to grouping and dragging the playgrounds there.


So, that means that you do prefer the Playground after all :)



> Please can we have this grouping back somehow. I dont care about
> the window menu itself but the grouping avoids the windows hell and we
> should get this back.


> In the long term I envision that I can drag windows (like playgrounds or
> Nautilus) onto each other
> and when I do this long enough they will group automagically.
>

That might be a solution, but what we have now is not such a solution.
Please give us time.


Doru



-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] Plague Doctor

[kilon alios]

Easier for you or me ? :D

Unfortunately my free time is too limited to try everything that pops up to
the mailing list to later find out that I can't get it to work because of
limited/non existent  documentation  and me having no clue what the thing
is doing or spend time on something that does not interest me. So its
easier to just ignore it and move on.

But since I am super interested to solutions that make managing windows
more manageable (pun intended) I can't resist trying this out.

On Fri, Jan 30, 2015 at 4:35 PM, Roberto Minelli 
wrote:

> Woop, didn't check for copyright when I did the poster. However, the
> Plague Doctor monitors the usage of windows in the Pharo IDE and closes the
> ones that are likely not to be used. It uses (optional) visual clues the
> "importance" of a windows (heat scale from blue to red) and fades away not
> used windows.
>
> It's easier if you give it a try!
>
> On 30 Jan 2015, at 12:57, kilon alios  wrote:
>
> Bare in mind that using Copyrighted images without the permission of the
> author makes you liable to be sued.
>
> So what is Plague Doctor ? The smalltalkhub description does not help at
> all, what is that "window plague" ?
>
> On Fri, Jan 30, 2015 at 1:28 PM, stepharo  wrote:
>
>>  :)
>>
>> Great picture! I love Plague Doctor
>> freaking guy.
>>
>> Stef
>>
>> Le 30/1/15 11:29, Roberto Minelli a écrit :
>>
>> To follow Stef’s advice of advertising our projects, here is the Plague
>> Doctor!
>>
>>  During development your Pharo IDE will quickly become overcrowded with
>> unused windows. The Plague Doctor is a tool, inspired by Autumn Leaves,
>> that helps you to mitigate this issue by closing the windows that you are
>> less likely to use in the future.
>>
>>  If you want to try our prototype, please install it with the following
>> script or ask me for a quick demo (I am Lille for the PharoDays!).
>>
>>  Gofer new
>>   smalltalkhubUser: 'RobertoMinelli' project: 'PlagueDoctor';
>>   package: 'ConfigurationOfPlagueDoctor';
>>   load.
>> (Smalltalk at: #ConfigurationOfPlagueDoctor) loadDevelopment.
>>
>>  
>>
>>  http://smalltalkhub.com/#!/~RobertoMinelli/PlagueDoctor
>>
>>  P.s. If you report a problem or a feature request, please file in an
>> entry
>> https://github.com/RobertoMinelli/PlagueDoctor/issues
>>
>>
>>
>

Re: [Pharo-dev] Plague Doctor

[Roberto Minelli]

Woop, didn't check for copyright when I did the poster. However, the Plague 
Doctor monitors the usage of windows in the Pharo IDE and closes the ones that 
are likely not to be used. It uses (optional) visual clues the "importance" of 
a windows (heat scale from blue to red) and fades away not used windows.

It's easier if you give it a try!

> On 30 Jan 2015, at 12:57, kilon alios  wrote:
> 
> Bare in mind that using Copyrighted images without the permission of the 
> author makes you liable to be sued. 
> 
> So what is Plague Doctor ? The smalltalkhub description does not help at all, 
> what is that "window plague" ? 
> 
>> On Fri, Jan 30, 2015 at 1:28 PM, stepharo  wrote:
>> :)
>> 
>> Great picture! I love Plague Doctor
>> freaking guy.
>> 
>> Stef
>> 
>> Le 30/1/15 11:29, Roberto Minelli a écrit :
>>> To follow Stef’s advice of advertising our projects, here is the Plague 
>>> Doctor!
>>> 
>>> During development your Pharo IDE will quickly become overcrowded with 
>>> unused windows. The Plague Doctor is a tool, inspired by Autumn Leaves, 
>>> that helps you to mitigate this issue by closing the windows that you are 
>>> less likely to use in the future.
>>> 
>>> If you want to try our prototype, please install it with the following 
>>> script or ask me for a quick demo (I am Lille for the PharoDays!).
>>> 
>>> Gofer new
>>>   smalltalkhubUser: 'RobertoMinelli' project: 'PlagueDoctor'; 
>>>   package: 'ConfigurationOfPlagueDoctor';
>>>   load.
>>> (Smalltalk at: #ConfigurationOfPlagueDoctor) loadDevelopment. 
>>> 
>>> 
>>> 
>>> http://smalltalkhub.com/#!/~RobertoMinelli/PlagueDoctor
>>> 
>>> P.s. If you report a problem or a feature request, please file in an entry
>>> https://github.com/RobertoMinelli/PlagueDoctor/issues
> 

Re: [Pharo-dev] Fwd: 14827 ProtoObject>>pointersTo failing circular references

[Ben Coman]

Yes. I just got back to looking at it and noticed the culprit was
printString.  Now  #printString --> #printStringLimitedTo: -->
#streamContents:limitedTo:  which uses LimitedWriteStream that should
protect against such recursion.

However  Array>>printOn:  is...

self shouldBePrintedAsLiteral ifTrue: [self printAsLiteralFormOn: aStream.
^ self].
self isSelfEvaluating ifTrue: [self printAsSelfEvaluatingFormOn: aStream. ^
self].
super printOn: aStream

where  #shouldBePrintedAsLiteral  and  #isSelfEvaluating recursively call
themselves - bypassing the protection of LimitedWriteStream.

As an aside,   Array>>shouldBePrintedAsLiteral  seems identical to
 Array>>isLiteral  -- so is it redundant and the former be deprecated?

Now I don't quite follow the semantics of #isLiteral and #isSelfEvaluating
for Arrays.

a := #( 1 2 { 3 . 4 } 5).
a isLiteral. "true"
a isSelfEvaluating. "true"

b := { 1 . 2 . #( 3 4 ) . 5 }.
b isLiteral. "true"
b isSelfEvaluating. "true"

So can someone provide an example for an Array where  #isLiteral  or
 #isSelfEvaluating   are false ?  Otherwise it seems it will always take
the first condition of Array>>printOn: .

cheers -ben

On Fri, Jan 30, 2015 at 9:23 PM, Nicolai Hess  wrote:

> Quick and Dirty,
> replace Array>>#printOn:
> with
>
> printOn: aStream
> self class = Array ifTrue: [self printAsSelfEvaluatingFormOn: aStream.
> ^ self].
> super printOn: aStream
>
> testObject := 'TEST'.
> ref1 := { testObject. nil }.
> ref2 := { ref1 }.
> ref3 := { ref2 }.
> ref1 at: 2 put: ref3.  "note the reference loop this creates"
> testObject pointersTo asString
>
> works
>
>
> 2015-01-30 14:15 GMT+01:00 Nicolai Hess :
>
>> Hi Ben,
>>
>> i don't know exactly what is happening here, but (size vs. inpsect)
>>
>> testObject := 'TEST'.
>> ref1 := { testObject. nil }.
>> ref2 := { ref1 }.
>> ref3 := { ref2 }.
>> ref1 at: 2 put: ref3.  "note the reference loop this creates"
>> testObject pointersTo size
>> -> 5
>>
>>
>>
>> works. So, the problem is not in #pointersTo but inspecting the result
>> array has one or more recursive self calls
>> to its elements.
>>
>>
>>
>>
>> 2015-01-30 3:59 GMT+01:00 Ben Coman :
>>
>>>
>>> I am revisiting my PointerDetective tool, which relies heavily on
>>> ProtoObject>>pointersTo.
>>>
>>> The example I recorded at the repository home page is currently locking
>>> & crashing the image due to #pointersTo being unable to handle the circular
>>> reference.  This "must" have been working on Windows at least around August
>>> 2014, but I've been unable to reproduce a working case since my Windows
>>> laptop died and I've since moved to OSX.
>>>
>>> On OSX, in a fresh image 40467 and latest vm 402, the following crashes
>>> the image...
>>>
>>> testObject := 'TEST'.
>>> ref1 := { testObject. nil }.
>>> ref2 := { ref1 }.
>>> ref3 := { ref2 }.
>>> ref1 at: 2 put: ref3.  "note the reference loop this creates"
>>> testObject pointersTo inspect.
>>>
>>> OSX Memory Monitor shows memory usage shoot from 50MB to >500MB in a few
>>> seconds, then usually the image crashes, but sometimes just hangs.
>>>
>>> I've logged...
>>> https://pharo.fogbugz.com/default.asp?14827
>>>
>>> cheers -ben
>>>
>>>
>>
>

Re: [Pharo-dev] Create window group for Playground

[Torsten Bergmann]

>Peter Uhnák
>It's still a regular window, so it's possible, the only difference is missing 
>button for it, which according to Tudor was removed purposefully.
> 
>http://forum.world.st/GT-Playground-Inspect-window-menu-tp4782020p4782044.html

Looks like I missed this thread. Tudor comment is a little bit funny there: "by 
default in Morphic every window gets the generic menu that 
nobody really uses,". When he does not use it it does not mean that all other 
do not use it ;)
I like when we make progress - but we should also take care not to constantly 
break others flow. 

I also currently circumvent the missing functionality the same way as Kilon 
describes: by opening an old workspace first, 
switching to grouping and dragging the playgrounds there. Please can we have 
this grouping back somehow. I dont care about 
the window menu itself but the grouping avoids the windows hell and we should 
get this back. 

In the long term I envision that I can drag windows (like playgrounds or 
Nautilus) onto each other
and when I do this long enough they will group automagically.

Bye
T.



 
 

Re: [Pharo-dev] Fwd: 14827 ProtoObject>>pointersTo failing circular references

[Nicolai Hess]

Quick and Dirty,
replace Array>>#printOn:
with

printOn: aStream
self class = Array ifTrue: [self printAsSelfEvaluatingFormOn: aStream.
^ self].
super printOn: aStream

testObject := 'TEST'.
ref1 := { testObject. nil }.
ref2 := { ref1 }.
ref3 := { ref2 }.
ref1 at: 2 put: ref3.  "note the reference loop this creates"
testObject pointersTo asString

works


2015-01-30 14:15 GMT+01:00 Nicolai Hess :

> Hi Ben,
>
> i don't know exactly what is happening here, but (size vs. inpsect)
>
> testObject := 'TEST'.
> ref1 := { testObject. nil }.
> ref2 := { ref1 }.
> ref3 := { ref2 }.
> ref1 at: 2 put: ref3.  "note the reference loop this creates"
> testObject pointersTo size
> -> 5
>
>
>
> works. So, the problem is not in #pointersTo but inspecting the result
> array has one or more recursive self calls
> to its elements.
>
>
>
>
> 2015-01-30 3:59 GMT+01:00 Ben Coman :
>
>>
>> I am revisiting my PointerDetective tool, which relies heavily on
>> ProtoObject>>pointersTo.
>>
>> The example I recorded at the repository home page is currently locking &
>> crashing the image due to #pointersTo being unable to handle the circular
>> reference.  This "must" have been working on Windows at least around August
>> 2014, but I've been unable to reproduce a working case since my Windows
>> laptop died and I've since moved to OSX.
>>
>> On OSX, in a fresh image 40467 and latest vm 402, the following crashes
>> the image...
>>
>> testObject := 'TEST'.
>> ref1 := { testObject. nil }.
>> ref2 := { ref1 }.
>> ref3 := { ref2 }.
>> ref1 at: 2 put: ref3.  "note the reference loop this creates"
>> testObject pointersTo inspect.
>>
>> OSX Memory Monitor shows memory usage shoot from 50MB to >500MB in a few
>> seconds, then usually the image crashes, but sometimes just hangs.
>>
>> I've logged...
>> https://pharo.fogbugz.com/default.asp?14827
>>
>> cheers -ben
>>
>>
>

Re: [Pharo-dev] Fwd: 14827 ProtoObject>>pointersTo failing circular references

[Nicolai Hess]

Hi Ben,

i don't know exactly what is happening here, but (size vs. inpsect)

testObject := 'TEST'.
ref1 := { testObject. nil }.
ref2 := { ref1 }.
ref3 := { ref2 }.
ref1 at: 2 put: ref3.  "note the reference loop this creates"
testObject pointersTo size
-> 5



works. So, the problem is not in #pointersTo but inspecting the result
array has one or more recursive self calls
to its elements.




2015-01-30 3:59 GMT+01:00 Ben Coman :

>
> I am revisiting my PointerDetective tool, which relies heavily on
> ProtoObject>>pointersTo.
>
> The example I recorded at the repository home page is currently locking &
> crashing the image due to #pointersTo being unable to handle the circular
> reference.  This "must" have been working on Windows at least around August
> 2014, but I've been unable to reproduce a working case since my Windows
> laptop died and I've since moved to OSX.
>
> On OSX, in a fresh image 40467 and latest vm 402, the following crashes
> the image...
>
> testObject := 'TEST'.
> ref1 := { testObject. nil }.
> ref2 := { ref1 }.
> ref3 := { ref2 }.
> ref1 at: 2 put: ref3.  "note the reference loop this creates"
> testObject pointersTo inspect.
>
> OSX Memory Monitor shows memory usage shoot from 50MB to >500MB in a few
> seconds, then usually the image crashes, but sometimes just hangs.
>
> I've logged...
> https://pharo.fogbugz.com/default.asp?14827
>
> cheers -ben
>
>

Re: [Pharo-dev] Create window group for Playground

[kilon alios]

personally I dont even understand why one would not want tabs, especially
in such a heavy window orientated enviroment like Pharo. Sure if I better
solution existed yes, but even in MacOS while mission control existed for
quite some time (offers a bird eye view of opened windows) still Apple was
forced to implement tabs even inside Finder. Tabs are actually a standard
feature for all applications nowdays and is strange that Pharo has hidden
it inside menus.

I completely agree with you that drag and drop or at least some other easy
to use solution would be ideal.

On Fri, Jan 30, 2015 at 3:00 PM, Ben Coman  wrote:

> maybe it should just be enabled permanently? defaulting to showing a tab
> when only one window is present - just the same as you get with a web
> browser.  I think this paradigm is common enough with web browsers today
> being able to drag/drop tabs is a common enough that this will be
> discoverable for most people.
>
> Perhaps a preference to turn it off as a backup for those that don't like
> it?
>
> btw,
>
> cheers -ben
>
> On Fri, Jan 30, 2015 at 8:48 PM, Tudor Girba  wrote:
>
>> I know about the feature, but we did not yet find a proper solution for
>> it.
>>
>> The current default solution does not make for a good user experience: I
>> have to click an obscure menu item just to make the window be a drop target
>> and I get no visual feedback of what can be dropped on it. The issue of
>> many windows is a significant problem that deserves a closer attention.
>>
>> I am sure it will take a while, though.
>>
>> Cheers,
>> Doru
>>
>>
>> On Fri, Jan 30, 2015 at 11:11 AM, stepharo  wrote:
>>
>>> Another features that nobody knows (even us).
>>>
>>> Stef
>>>
>>> Le 29/1/15 18:51, Torsten Bergmann a écrit :
>>>
>>>  Previous (and still included) Workspace, Transcript and Nautilus
 provide Window grouping by selecting "Create window group" from the
 window menu and then dragging two windows onto each other.
 They are grouped together in one single window then and each one
 gets a tab.

 Looks like Playground does not support this feature yet - so currently
 I end up with many many windows which for me is a step backwards
 compared to working with workspaces in Pharo 3.0

 What is necessary to provide this for the Playground so we have a
 common behavior for all the tools and a cleaner desktop?

 Thanks
 T.



>>>
>>>
>>
>>
>> --
>> www.tudorgirba.com
>>
>> "Every thing has its own flow"
>>
>
>

Re: [Pharo-dev] Create window group for Playground

[Ben Coman]

maybe it should just be enabled permanently? defaulting to showing a tab
when only one window is present - just the same as you get with a web
browser.  I think this paradigm is common enough with web browsers today
being able to drag/drop tabs is a common enough that this will be
discoverable for most people.

Perhaps a preference to turn it off as a backup for those that don't like
it?

btw,

cheers -ben

On Fri, Jan 30, 2015 at 8:48 PM, Tudor Girba  wrote:

> I know about the feature, but we did not yet find a proper solution for it.
>
> The current default solution does not make for a good user experience: I
> have to click an obscure menu item just to make the window be a drop target
> and I get no visual feedback of what can be dropped on it. The issue of
> many windows is a significant problem that deserves a closer attention.
>
> I am sure it will take a while, though.
>
> Cheers,
> Doru
>
>
> On Fri, Jan 30, 2015 at 11:11 AM, stepharo  wrote:
>
>> Another features that nobody knows (even us).
>>
>> Stef
>>
>> Le 29/1/15 18:51, Torsten Bergmann a écrit :
>>
>>  Previous (and still included) Workspace, Transcript and Nautilus
>>> provide Window grouping by selecting "Create window group" from the
>>> window menu and then dragging two windows onto each other.
>>> They are grouped together in one single window then and each one
>>> gets a tab.
>>>
>>> Looks like Playground does not support this feature yet - so currently
>>> I end up with many many windows which for me is a step backwards
>>> compared to working with workspaces in Pharo 3.0
>>>
>>> What is necessary to provide this for the Playground so we have a
>>> common behavior for all the tools and a cleaner desktop?
>>>
>>> Thanks
>>> T.
>>>
>>>
>>>
>>
>>
>
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"
>

Re: [Pharo-dev] Create window group for Playground

[Tudor Girba]

Hi,

The philosophy in the GT team is not to remove things from the existing
environment, but to start from scratch and add the things that fit. This is
the only way to get to completely new solutions.

This is one of those interesting ideas that just did not fit in the current
form.

Cheers,
Doru



On Fri, Jan 30, 2015 at 12:16 PM, Peter Uhnák  wrote:

> It's still a regular window, so it's possible, the only difference is
> missing button for it, which according to Tudor was removed purposefully.
>
>
> http://forum.world.st/GT-Playground-Inspect-window-menu-tp4782020p4782044.html
>
> On Fri, Jan 30, 2015 at 12:10 PM, stepharo  wrote:
>
>>
>> Le 30/1/15 11:20, kilon alios a écrit :
>>
>>> Do you want to hear the irony , I only use Workspace to create a window
>>> group to act as a container for Playgrounds :D
>>>
>> D
>>
>>
>>
>>
>>
>>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] Create window group for Playground

[Tudor Girba]

I know about the feature, but we did not yet find a proper solution for it.

The current default solution does not make for a good user experience: I
have to click an obscure menu item just to make the window be a drop target
and I get no visual feedback of what can be dropped on it. The issue of
many windows is a significant problem that deserves a closer attention.

I am sure it will take a while, though.

Cheers,
Doru


On Fri, Jan 30, 2015 at 11:11 AM, stepharo  wrote:

> Another features that nobody knows (even us).
>
> Stef
>
> Le 29/1/15 18:51, Torsten Bergmann a écrit :
>
>  Previous (and still included) Workspace, Transcript and Nautilus
>> provide Window grouping by selecting "Create window group" from the
>> window menu and then dragging two windows onto each other.
>> They are grouped together in one single window then and each one
>> gets a tab.
>>
>> Looks like Playground does not support this feature yet - so currently
>> I end up with many many windows which for me is a step backwards
>> compared to working with workspaces in Pharo 3.0
>>
>> What is necessary to provide this for the Playground so we have a
>> common behavior for all the tools and a cleaner desktop?
>>
>> Thanks
>> T.
>>
>>
>>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] Create window group for Playground

[Ben Coman]

On Fri, Jan 30, 2015 at 6:20 PM, kilon alios  wrote:

> you dont watch my video tutorials ? ;D
>
>
>
Your video is where I learnt about it. thanks Kilon.

Re: [Pharo-dev] Create window group for Playground

[Peter Uhnák]

It's still a regular window, so it's possible, the only difference is
missing button for it, which according to Tudor was removed purposefully.

http://forum.world.st/GT-Playground-Inspect-window-menu-tp4782020p4782044.html

On Fri, Jan 30, 2015 at 12:10 PM, stepharo  wrote:

>
> Le 30/1/15 11:20, kilon alios a écrit :
>
>> Do you want to hear the irony , I only use Workspace to create a window
>> group to act as a container for Playgrounds :D
>>
> D
>
>
>
>
>
>

Re: [Pharo-dev] Create window group for Playground

[stepharo]

Le 30/1/15 11:20, kilon alios a écrit :
Do you want to hear the irony , I only use Workspace to create a 
window group to act as a container for Playgrounds :D

D

Re: [Pharo-dev] Spec MenuModel not working

[Peter Uhnák]

I created an issue here
https://pharo.fogbugz.com/f/cases/14829/Spec-MenuModel-submenu-not-working

I also found the breaking commit
https://github.com/pharo-project/pharo-core/commit/1c3c757366ba2cad8f367ee957a228d54414fd74
but Stef probably knows best what was going on there.

Peter

On Sat, Dec 20, 2014 at 8:03 PM, Nicolai Hess  wrote:

>
>
> 2014-12-20 9:54 GMT+01:00 stepharo :
>
>>  Hi nicolai
>>
>> could you publish your code somewhere?
>>
>
> see attachement dock_menu_spec.cs
>
>
>
>

[Pharo-dev] [pharo-project/pharo-core] 13864c: 40469

[GitHub]

  Branch: refs/heads/4.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 13864c112fbf1b6d2a2d6ba7a6a0a9d3596ba35d
  
https://github.com/pharo-project/pharo-core/commit/13864c112fbf1b6d2a2d6ba7a6a0a9d3596ba35d
  Author: Jenkins Build Server 
  Date:   2015-01-30 (Fri, 30 Jan 2015)

  Changed paths:
M 
OpalCompiler-Core.package/AbstractCompiler.class/class/settings/compilerSettingsOn_.st
M 
OpalCompiler-Core.package/CCompilationContext.class/class/initialize/initialize.st
M OpalCompiler-Core.package/CCompilationContext.class/definition.st
A 
OpalCompiler-Core.package/CCompilationContext.class/instance/accessing/encoderClass.st
A 
OpalCompiler-Core.package/CCompilationContext.class/instance/accessing/encoderClass_.st
M 
OpalCompiler-Core.package/CompilationContext.class/class/initialize/initialize.st
M OpalCompiler-Core.package/CompilationContext.class/definition.st
A 
OpalCompiler-Core.package/CompilationContext.class/instance/accessing/encoderClass.st
A 
OpalCompiler-Core.package/CompilationContext.class/instance/accessing/encoderClass_.st
M OpalCompiler-Core.package/IRBytecodeDecompiler.class/instance/quick 
methods/quickMethod.st
A OpalCompiler-Core.package/IRBytecodeGenerator.class/class/instance 
creation/newWithEncoderClass_.st
M OpalCompiler-Core.package/IRBytecodeGenerator.class/definition.st
M 
OpalCompiler-Core.package/IRBytecodeGenerator.class/instance/accessing/encoderClass.st
A 
OpalCompiler-Core.package/IRBytecodeGenerator.class/instance/accessing/encoderClass_.st
M 
OpalCompiler-Core.package/IRTranslatorV2.class/instance/initialize/initialize.st
M 
OpalCompiler-Tests.package/OCBytecodeGeneratorTest.class/instance/helper/newBytecodeGen.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script469.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40469.st
M 
ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
M Tool-Base.package/PharoCommonTools.class/class/settings/settingsOn_.st

  Log Message:
  ---
  40469
14811 Fix settings for OpalCompiler with new bytecode generator
https://pharo.fogbugz.com/f/cases/14811

10529 ToolRegistry need to support multiple registrations per tool 
https://pharo.fogbugz.com/f/cases/10529

http://files.pharo.org/image/40/40469.zip

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

  Branch: refs/tags/40469
  Home:   https://github.com/pharo-project/pharo-core

Re: [Pharo-dev] Create window group for Playground

[kilon alios]

you dont watch my video tutorials ? ;D

here is one for window groups

https://www.youtube.com/watch?v=GGJZeajjWGU&index=12&list=PLqbtQ7OkSta0ULYAd7Qdxof851ybh-_m_

I agree this one of the features that I really miss and I think I was the
first one to report it in this least when Playground was announced it for
Pharo 4. Yes Peter I am using your workaround to compensate for this.

Do you want to hear the irony , I only use Workspace to create a window
group to act as a container for Playgrounds :D

Actually finding a way to create tabs for the guis in Pharo had been one of
my first priorities to develop but when I reported my idea in this mailing
list I was informed that the feature already existed. I was so happy I made
a video tutorial about it because its a pity so useful features to be so
hidden from the user. Probably an Icon would have made it way more obvious
to most users.

On Fri, Jan 30, 2015 at 12:11 PM, stepharo  wrote:

> Another features that nobody knows (even us).
>
> Stef
>
> Le 29/1/15 18:51, Torsten Bergmann a écrit :
>
>  Previous (and still included) Workspace, Transcript and Nautilus
>> provide Window grouping by selecting "Create window group" from the
>> window menu and then dragging two windows onto each other.
>> They are grouped together in one single window then and each one
>> gets a tab.
>>
>> Looks like Playground does not support this feature yet - so currently
>> I end up with many many windows which for me is a step backwards
>> compared to working with workspaces in Pharo 3.0
>>
>> What is necessary to provide this for the Playground so we have a
>> common behavior for all the tools and a cleaner desktop?
>>
>> Thanks
>> T.
>>
>>
>>
>
>

Re: [Pharo-dev] Create window group for Playground

[stepharo]

Another features that nobody knows (even us).

Stef

Le 29/1/15 18:51, Torsten Bergmann a écrit :

Previous (and still included) Workspace, Transcript and Nautilus
provide Window grouping by selecting "Create window group" from the
window menu and then dragging two windows onto each other.
They are grouped together in one single window then and each one
gets a tab.

Looks like Playground does not support this feature yet - so currently
I end up with many many windows which for me is a step backwards
compared to working with workspaces in Pharo 3.0

What is necessary to provide this for the Playground so we have a
common behavior for all the tools and a cleaner desktop?

Thanks
T.

Re: [Pharo-dev] pharo-os : a fantasy!

[stepharo]

Keep pushing this idea.

Stef

Le 26/1/15 14:17, Mayuresh Kathe a écrit :

hi,

i have been investigating a full blown gnu/linux based distribution
focused entirely on pharo as the the user interface layer.

looks like, if the entire base 'os' functionality is exposed via this
little environment/toolkit called "sysctl", building a pure object
oriented layer of shell scripts to support all calls exposed via sysctl
and managed via pharo looks feasible.

i might be wrong, and look forward to experienced folks pointing out
flaws in my thought process.

if this organization/architecture feels sound, i would like to get a
go-ahead to hire the services of a gnu/linux expert to start building
the base layer atop which pharo can be run as the only application.

this effort would be funded out of my own pockets (which aren't very
deep).  :)

~mayuresh

[Pharo-dev] [pharo-project/pharo-core] 7b0188: 40468

[GitHub]

  Branch: refs/heads/4.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 7b01889418cc4bededd2c57794088a708178666c
  
https://github.com/pharo-project/pharo-core/commit/7b01889418cc4bededd2c57794088a708178666c
  Author: Jenkins Build Server 
  Date:   2015-01-30 (Fri, 30 Jan 2015)

  Changed paths:
R AST-Core.package/RBArrayNode.class/instance/accessing/start_.st
R AST-Core.package/RBArrayNode.class/instance/accessing/stop_.st
R AST-Core.package/RBAssignmentNode.class/instance/accessing/start_.st
R AST-Core.package/RBAssignmentNode.class/instance/accessing/stop_.st
R AST-Core.package/RBBlockNode.class/instance/accessing/start_.st
R AST-Core.package/RBBlockNode.class/instance/accessing/stop_.st
R AST-Core.package/RBCascadeNode.class/instance/accessing/start_.st
R AST-Core.package/RBCascadeNode.class/instance/accessing/stop_.st
R AST-Core.package/RBIdentifierToken.class/instance/accessing/stop.st
R AST-Core.package/RBIdentifierToken.class/instance/accessing/stop_.st
R AST-Core.package/RBKeywordToken.class/instance/accessing/stop.st
R AST-Core.package/RBKeywordToken.class/instance/accessing/stop_.st
R AST-Core.package/RBLiteralArrayNode.class/instance/accessing/start_.st
R AST-Core.package/RBLiteralArrayNode.class/instance/accessing/stop_.st
R AST-Core.package/RBLiteralValueNode.class/instance/accessing/start_.st
R AST-Core.package/RBLiteralValueNode.class/instance/accessing/stop_.st
R AST-Core.package/RBMessageNode.class/instance/accessing/start_.st
R AST-Core.package/RBMessageNode.class/instance/accessing/stop_.st
R AST-Core.package/RBParseErrorNode.class/instance/accessing/start_.st
R AST-Core.package/RBParseErrorNode.class/instance/accessing/stop_.st
R AST-Core.package/RBPragmaNode.class/instance/accessing/start_.st
R AST-Core.package/RBPragmaNode.class/instance/accessing/stop_.st
R AST-Core.package/RBProgramNode.class/instance/accessing/start_.st
R AST-Core.package/RBProgramNode.class/instance/accessing/stop_.st
R 
AST-Core.package/RBProgramNode.class/instance/replacing/calculateInnerCommentsSize_.st
R 
AST-Core.package/RBProgramNode.class/instance/replacing/calculateSourceInterval_.st
R 
AST-Core.package/RBProgramNode.class/instance/replacing/checkMessageNodesIn_withDifference_with_.st
M AST-Core.package/RBProgramNode.class/instance/replacing/replaceWith_.st
R AST-Core.package/RBReturnNode.class/instance/accessing/start_.st
R AST-Core.package/RBSequenceNode.class/instance/accessing/start_.st
R AST-Core.package/RBSequenceNode.class/instance/accessing/stop_.st
R AST-Core.package/RBToken.class/instance/accessing/sourcePointer_.st
R AST-Core.package/RBVariableNode.class/instance/accessing/start_.st
R AST-Core.package/RBVariableNode.class/instance/accessing/stop_.st
M 
AST-Tests-Core.package/RBProgramNodeTest.class/instance/testing-replacing/testReplaceAssignment.st
M 
AST-Tests-Core.package/RBProgramNodeTest.class/instance/testing-replacing/testReplaceBlock.st
M 
AST-Tests-Core.package/RBProgramNodeTest.class/instance/testing-replacing/testReplaceLiteral.st
M 
AST-Tests-Core.package/RBProgramNodeTest.class/instance/testing-replacing/testReplaceLiteralArray1.st
M 
AST-Tests-Core.package/RBProgramNodeTest.class/instance/testing-replacing/testReplaceLiteralArray2.st
M 
AST-Tests-Core.package/RBProgramNodeTest.class/instance/testing-replacing/testReplaceMessage.st
M 
AST-Tests-Core.package/RBProgramNodeTest.class/instance/testing-replacing/testReplaceMessageArgument.st
M 
AST-Tests-Core.package/RBProgramNodeTest.class/instance/testing-replacing/testReplaceMessageReceiver.st
M 
AST-Tests-Core.package/RBProgramNodeTest.class/instance/testing-replacing/testReplaceVariable.st
M 
NECompletion.package/NECMenuMorph.class/instance/drawing/drawLine_on_rectangle_.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script468.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40468.st
M 
ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st

  Log Message:
  ---
  40468
14815 NECMenuMorph should clip the canvas during menu items drawing
https://pharo.fogbugz.com/f/cases/14815

14730 Reverting 14254
https://pharo.fogbugz.com/f/cases/14730

http://files.pharo.org/image/40/40468.zip

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

  Branch: refs/tags/40468
  Home:   https://github.com/pharo-project/pharo-core