Re: [Pharo-users] Spec: Populating a playground with a particular content (was Re: Spec: Binding widgets how to)

[Offray Vladimir Luna Cárdenas]

Hi,

Lets try something simpler. Consider this code:

=
| data m1 m2 |

data := { 'first' -> 'I\"m just text' . 'second' -> 'ProfStef 
openPharoZenWorkspace'} asOrderedDictionary.


m1 := DynamicComposableModel new.
m1 instantiateModels: #(list ListModel).
m1 list items: (data keys).
m1 layout:
(SpecLayout composed
add: #list;
yourself).

m2 := DynamicComposableModel new.
m2 instantiateModels: #(right TextModel).
m2 assign: m1 to: #left.
m1 list
whenSelectedItemChanged: [:item |
item
ifNil: [
m2 instantiateModels: #(right TextModel).
m2 right text: ''
]
ifNotNil: [
item = 'first'
ifTrue: [
m2 instantiateModels: #(right TextModel).
Transcript show: m2 right asString, String cr
].
item = 'second'
ifTrue: [
m2 instantiateModels: #(right 
GlamourPresentationModel).

Transcript show: m2 right asString, String cr].
]
].

m2 layout:
(SpecLayout composed
newRow: [:r | r add: #left; add: #right];
yourself).
m2 openWithSpec

=

Shouldn't be #right dynamically defined according to the values of 
'item' and be replaced on the m2 layout? The transcript show that 
anytime I change the selection in this small spec interface, m2 right is 
changed. Is it not what I'm putting in the right side of the interface 
with the line which says:  "newRow: [:r | r add: #left; add: #right];"


How can I made spec in this small example show the respective value in 
the dictionary when the key value is "first" inside a TextModel and the 
respective value in the dictionary when the key value is "second" inside 
a GlamourPresentationModel?


Cheers,

Offray

On 08/01/16 19:06, Offray Vladimir Luna Cárdenas wrote:

Hi Johan,

I have not found more errors on the booklet, but I think that I'm not 
getting the explanation of dynamic spec. Consider this code:



==
GrafoscopioGUI Class>>exampleBootstrapDynamicUI
"Starting from an example UI from the Spec-Glamour, to customize 
towards the grafoscopio

UI and get some ideas"

|notebook leftUpperPanel leftPanel treeBrowser |

"Creating a notebook-tree with dummy data"
notebook := GrafoscopioNode new becomeDefaultTestTree.

"Defining the tree roots part"
leftUpperPanel := DynamicComposableModel new.
leftUpperPanel instantiateModels: #(tree TreeModel).
leftUpperPanel tree
roots: notebook children;
childrenBlock: [:node | node children ];
displayBlock: [:node | node title ].
leftUpperPanel layout: (SpecLayout composed
add: #tree;
yourself).
"to debug upto here uncomment the next line, and comment all other 
'openWithSpec' ones"

"leftUpperPanel openWithSpec."

"Integrating the previous tree with the node header and creating 
the body according to

the tags on the node"
leftPanel := DynamicComposableModel new.
leftPanel assign: leftUpperPanel to: #roots.
leftPanel instantiateModels: #(header TextInputFieldModel).
treeBrowser := DynamicComposableModel new.
leftUpperPanel tree
whenSelectedItemChanged: [:node |
node
ifNil:[
leftPanel header text: ''.
treeBrowser instantiateModels: #(body TextModel).
Transcript show: 'Nada que mostrar', String cr]
ifNotNil: [
leftPanel header text: (leftUpperPanel tree 
selectedItem content header).
leftUpperPanel tree selectedItem content tags = 
'código'

ifTrue: [
treeBrowser instantiateModels: #(body 
GlamourPresentationModel).

Transcript show: 'I am code', String cr.
Transcript show: treeBrowser body 
asString, String cr.

]
ifFalse: [
treeBrowser instantiateModels: #(body 
TextModel).
treeBrowser body text: (leftUpperPanel 
tree selectedItem content body).

Transcript show: 'I am NOT code', String cr.
Transcript show: treeBrowser body 
asString, String cr.

]
]
].
leftPanel layout:
(SpecLayout composed
newColumn: [:column |
column
add: #roots;
add: #header height: 35];
yourself).

"Integrating the previous tree with node body content"
treeBrowser assign: leftPanel to: #leftTree.
treeBrowser layout:
(SpecLayout composed
newRow: [:r | r add: #leftTree; add: 

Re: [Pharo-users] Spec: Populating a playground with a particular content (was Re: Spec: Binding widgets how to)

[Offray Vladimir Luna Cárdenas]

Hi Johan,

I have not found more errors on the booklet, but I think that I'm not 
getting the explanation of dynamic spec. Consider this code:



==
GrafoscopioGUI Class>>exampleBootstrapDynamicUI
"Starting from an example UI from the Spec-Glamour, to customize 
towards the grafoscopio

UI and get some ideas"

|notebook leftUpperPanel leftPanel treeBrowser |

"Creating a notebook-tree with dummy data"
notebook := GrafoscopioNode new becomeDefaultTestTree.

"Defining the tree roots part"
leftUpperPanel := DynamicComposableModel new.
leftUpperPanel instantiateModels: #(tree TreeModel).
leftUpperPanel tree
roots: notebook children;
childrenBlock: [:node | node children ];
displayBlock: [:node | node title ].
leftUpperPanel layout: (SpecLayout composed
add: #tree;
yourself).
"to debug upto here uncomment the next line, and comment all other 
'openWithSpec' ones"

"leftUpperPanel openWithSpec."

"Integrating the previous tree with the node header and creating 
the body according to

the tags on the node"
leftPanel := DynamicComposableModel new.
leftPanel assign: leftUpperPanel to: #roots.
leftPanel instantiateModels: #(header TextInputFieldModel).
treeBrowser := DynamicComposableModel new.
leftUpperPanel tree
whenSelectedItemChanged: [:node |
node
ifNil:[
leftPanel header text: ''.
treeBrowser instantiateModels: #(body TextModel).
Transcript show: 'Nada que mostrar', String cr]
ifNotNil: [
leftPanel header text: (leftUpperPanel tree 
selectedItem content header).
leftUpperPanel tree selectedItem content tags = 
'código'

ifTrue: [
treeBrowser instantiateModels: #(body 
GlamourPresentationModel).

Transcript show: 'I am code', String cr.
Transcript show: treeBrowser body asString, 
String cr.

]
ifFalse: [
treeBrowser instantiateModels: #(body 
TextModel).
treeBrowser body text: (leftUpperPanel tree 
selectedItem content body).

Transcript show: 'I am NOT code', String cr.
Transcript show: treeBrowser body asString, 
String cr.

]
]
].
leftPanel layout:
(SpecLayout composed
newColumn: [:column |
column
add: #roots;
add: #header height: 35];
yourself).

"Integrating the previous tree with node body content"
treeBrowser assign: leftPanel to: #leftTree.
treeBrowser layout:
(SpecLayout composed
newRow: [:r | r add: #leftTree; add: #body ];
yourself
).
treeBrowser openWithSpec.
==

I can get the interface shown here:



and when I move between nodes in the upper left tree the correspondent 
name in the lower left input box changes accordingly, but nothing else 
happens on the right side panel. I have put the definition of the type 
and contents of such panel inside a whenSelectionChanged block, as you 
can see in the previous code, because I think that right panel should 
change according to the type of node that is selected, but this doesn't 
work. The debug info that I send to a transcript show that #body becomes 
a GlamourPresentationModel or a TextModel depending on which node I'm 
selecting. I don't know what I'm doing wrong or how this dynamic spec is 
supposed to behave... well, dynamically, and accordingly making layout 
components to change on the fly.


How can I make the right panel change to become a 
GlamourPresentationModel or a TextModel in Spec-Glamour?


Thanks,

Offray


On 08/01/16 12:10, Johan Fabry wrote:


Consider the error as reported! I should work on this text soon so I 
will fix it. If you find any more errors feel free to send me a mail.


On Jan 8, 2016, at 12:43, Offray Vladimir Luna Cárdenas 
mailto:off...@riseup.net>> wrote:


Thanks Johan,

This seems what I'm looking for.

I running now the examples at the dynamic spec section and I have 
found an error in Script 1.41: Setting up the sub widgets (pg 24 of 
current version) in the first line, where it says " view label text: 
'Packages:'." it should be " view label label: 'Packages:'." There is 
any place where I can report and/or correct such errors?


Cheers,

Offray

On 08/01/16 06:21, Johan Fabry wrote:

Hola,

it looks like what you want here is covered by dynamic spec. Have a 
look at the dynamic spec section in the Spec booklet (work in 
progress) 
https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgress/lastSuccessfulBui

Re: [Pharo-users] Crash or locked VM

[Nicolai Hess]

2016-01-08 23:20 GMT+01:00 Hilaire :

> Le 08/01/2016 21:31, Nicolai Hess a écrit :
> >
> >
> > The crashing image itself can be found there in case of
> usefulness
> > https://www.dropbox.com/s/rur8ayt8eon6mab/drgeo.image.zip?dl=0
> >
> >
> > Do you have the changes file, too?
>
> Here: https://www.dropbox.com/s/dwg99xmvtgak10o/DrGeoCrashVM.zip?dl=0
>
> Thanks
>
>
Hi Hilaire,

I think this is the same bug as
https://pharo.fogbugz.com/f/cases/13854/frameSize-calculated-wrongly-for-lineSegmentsDo

this is fixed in pharo4.0 and pharo5.0 but not in pharo3.0
I modified the changeset for pharo4.0 to make it loadable in pharo3.0
But I did not looked further on the code changes, maybe it won't fully work.
Find attached the changeset. You have to switch compiler class before and
after loading this.

SmalltalkImage compilerClass: Compiler.
'opal_drgeo.cs' asFileReference fileIn.
SmalltalkImage compilerClass: OpalCompiler.




> --
> Dr. Geo
> http://drgeo.eu
>
>
>
>
'From Pharo3.0 of 18 March 2013 [Latest update: #30864] on 9 January 2016 at 12:23:34.657922 am'!
IRStackCount subclass: #IRClosureStackCount
	instanceVariableNames: 'numMethodTempVars'
	classVariableNames: ''
	poolDictionaries: ''
	category: 'OpalCompiler-Core-Bytecode'!

!IRClosureStackCount commentStamp: '' prior: 0!
IRClosureStackCount is used to distinguish between a stack 
in the method scope and a stack within a closure block. The
closure stack size is independent of the number of tempvars from the compiled method, therefore that number is subtracted
from this stack size length.!


!IRBytecodeGenerator methodsFor: 'instructions' stamp: 'DrGeoUser 1/9/2016 00:03'!
pushClosureCopyNumCopiedValues: numCopied numArgs: numArgs2 to: toSeqId
	
	| blockSeqId |
	blockSeqId := self newDummySeqId.
	stack pop: numCopied. 
	stacks at: blockSeqId put: ((IRClosureStackCount new numMethodTempVars:(numberOfTemps)) startAt: (numArgs2+numCopied)).
	stack push.
	stacks at: toSeqId put: (stack linkTo: (stacks at: toSeqId ifAbsentPut: [nil])).
	self saveLastJump: (Message
		selector: #closureFrom:to:copyNumCopiedValues:numArgs:
		arguments: {currentSeqId.toSeqId. numCopied. numArgs2.}).

	self closureFrom: currentSeqId to: toSeqId copyNumCopiedValues: numCopied numArgs: numArgs2.
	self label: blockSeqId.
! !

!IRBytecodeGenerator methodsFor: 'instructions' stamp: 'DrGeoUser 1/9/2016 00:03'!
label: seqId
	lastSpecialReturn := nil.
	currentSeqId := seqId.
	currentSeqNum := currentSeqNum + 1.
	seqOrder at: seqId put: currentSeqNum.
	orderSeq at: currentSeqNum ifAbsentPut: [seqId].
	bytes := seqBytes at: seqId ifAbsentPut: [OrderedCollection new].
	jumps at: seqId ifAbsentPut: [nil].
	instrMap := instrMaps at: seqId ifAbsentPut: [OrderedCollection new].
	stack
		ifNil: [ stack := stacks at: currentSeqId ifAbsentPut: [ IRStackCount new ] ]
		ifNotNil: [stack := stacks at: currentSeqId ifAbsentPut: [ stack class newOn:stack ] ]! !


!IRStackCount methodsFor: 'results' stamp: 'NicolaiHess 11/8/2014 23:51'!
linkTo: stackOrNil

	stackOrNil ifNil: [^ self class newOn: self].
	^ self position = stackOrNil start
		ifTrue: [stackOrNil]
		ifFalse: [self error: 'stack out of sync in bytecode generator']! !


!IRClosureStackCount methodsFor: 'accessing' stamp: 'NicolaiHess 11/8/2014 23:47'!
numMethodTempVars
	^ numMethodTempVars! !

!IRClosureStackCount methodsFor: 'accessing' stamp: 'NicolaiHess 11/9/2014 00:05'!
numMethodTempVars: nilOrNumber
	numMethodTempVars := nilOrNumber ifNil:[0]! !

!IRClosureStackCount methodsFor: 'accessing' stamp: 'NicolaiHess 11/8/2014 23:47'!
length

	^ super length - self numMethodTempVars! !

!IRClosureStackCount methodsFor: 'initialize' stamp: 'NicolaiHess 11/8/2014 23:47'!
initialize

	super initialize.

	numMethodTempVars := 0.! !


!IRStackCount class methodsFor: 'instance creation' stamp: 'NicolaiHess 11/8/2014 23:50'!
newOn: stack

	^ self startAt: stack position! !


!IRClosureStackCount class methodsFor: 'instance creation' stamp: 'NicolaiHess 11/8/2014 23:54'!
newOn: stack
	^ (self startAt: stack position)
		numMethodTempVars: stack numMethodTempVars;
		yourself! !

Re: [Pharo-users] [Pharo-dev] [ann] gtdebugger in pharo 5.0

[Tudor Girba]

Hi,

Thanks a lot for the detailed feedback.

> On Jan 8, 2016, at 7:28 PM, Torsten Bergmann  > wrote:
> 
> Hi,
> 
> with a moldable debugger we should (in the future) be able to support
> debugging also different/other programming languages/DSLs in Pharo :) 

Yes. This would work quite well if the language would project on the AST of 
Pharo, like Helvetia does.


> - although usually one does necessary have such a use case. So I guess
> GTInspector or other will be adopted to own needs more than GTDebugger. 

The debugger can be specialized for specific libraries or frameworks, not only 
languages. For example, we currently have extensions for PetitParser, Glamour, 
Announcements and they are meaningful.


> However:
> The only objection so far is that I dislike the order/size of the panes.

That is actually encouraging :).


> The placement of the panes in GTDebugger (as for instance found in Moose)
> requires often to use the scrollbars of the pane showing the stack because
> of the text length. 

The horizontal bar could also be prevented by making the items in the list 
wrapped (so, they might occupy multiple lines).


> In GTDebugger the stack is at the top left, the source at the top right with 
> a common splitter beneath the two panes: therefore the height (depth) of the 
> stack pane is always the height of the code pane.
> When you have a long method to debug on the right much space is wasted for 
> a deep stack on the left although you might only be interested in a few top 
> frames.
> 
> Contrary when you have are interested in a deep/full stack and you increase 
> the
> height of the stack pane on the left you directly increase the height of the 
> code
> pane and for short methods you waste a lot of space in the source pane as 
> well.

The reason for this choice was to expose the developer to more of the stack, 
but it is not an essential design choice.


> This is much better solved with the positioning in the traditinal Debugger:
> - Stack 
> - Source
> - other 
> 
> So in my opinion We should preserve:
> 
>  - TOP:the stack at the top (using the full width of the window, so only 
> vertical scrolling
>has to be done to "roll" on the stack, no need for horizontal 
> scrolling as the area
>is wide enough)
>  - MIDDLE: the source code pane in the middle (also using the full width of 
> the window and there
>fore in alignment with code pane in the the usual tools like 
> Nautilus, change sorter, ...)
>  - BOTTON: one or more panel for inspection at the bottom

We will play with this a bit. Or does anyone else would like to give it a try?


> It would be OK for me if others like the new layout better - but at least 
> there should be an 
> option to support the traditional layout as well (or support pane 
> movemen/docking as in other IDEs) 

Movement would be certainly interesting and I would be happy if someone would 
implement this in Morphic.


> Also the debugger window in Moose wastes a lot of space/has unused space 
> within the 
> windows client are itself. For instance the splitters are very thick which 
> might be an issue of 
> the moose theme.

It’s actually an issue in Glamour, but it can be adapted.

Cheers,
Doru


> Thanks
> T. 
> 
> Gesendet: Freitag, 08. Januar 2016 um 11:24 Uhr
> Von: "Tudor Girba" mailto:tu...@tudorgirba.com>>
> An: "Pharo Development List"  >, "Moose-dev Moose Dev" 
> mailto:moose-...@iam.unibe.ch>>, "Any question about 
> pharo is welcome"  >
> Betreff: [Pharo-dev] [ann] gtdebugger in pharo 5.0
> 
> Hi,
>  
> We are about to integrate in Pharo a new member of the Glamorous Toolkit: the 
> GTDebugger. As this is a significant change that might affect your workflow, 
> here is some background information to help you deal with the change.
>  
> First, you should know that the change is not irreversible and it is easily 
> possible to disabled the new debugger through a setting. However, please do 
> take the time to provide us feedback if something does not work out for you. 
> We want to know what can be improved and we try to react as fast as we can.
>  
> A practical change comes from the fact that the variables are manipulated 
> through a GTInspector, which makes it cheaper to maintain in the longer run.
>  
> 
>  While the first thing that will capture the attention is the default generic 
> interface, the real power comes from the moldable nature of the debugger. 
> Like all other GT tools, GTDebugger is also moldable by design. This means 
> that we can construct custom debuggers for specific libraries at small costs 
> (often measured in a couple of hundred lines of code).
>  
> 
>  
> Here is an introductory overview blog post that also includes some links for 
> further reading:
> http://www.humane-assessment.com/blog/gtdebugger-in-pharo/ 
> 
>  
> Please le

Re: [Pharo-users] Crash or locked VM

[Hilaire]

Le 08/01/2016 21:31, Nicolai Hess a écrit :
>
>
> The crashing image itself can be found there in case of usefulness
> https://www.dropbox.com/s/rur8ayt8eon6mab/drgeo.image.zip?dl=0
>
>
> Do you have the changes file, too?

Here: https://www.dropbox.com/s/dwg99xmvtgak10o/DrGeoCrashVM.zip?dl=0

Thanks

-- 
Dr. Geo
http://drgeo.eu

Re: [Pharo-users] Crash or locked VM

[Nicolai Hess]

2016-01-08 21:01 GMT+01:00 stepharo :

> thanks hilaire.
>
> Stef
>
> Le 5/1/16 22:11, Hilaire a écrit :
>
> Hi,
>>
>> I have a situation with a recursive Dr. Geo script where the image crash
>> or get locked (Can't hold on the image).
>> I tried with latest VM as detailed in the joined crash dump.
>>
>> I did not get similar problem with other recursive script. So I may have
>> very special interaction between the objects, but I did not find out.
>>
>> It may also be related to Morph because when instantiating first the
>> canvas and its window (2nd line of the script), then the rest of the
>> script, it does not crash.
>>
>> The crashing image itself can be found there in case of usefulness
>> https://www.dropbox.com/s/rur8ayt8eon6mab/drgeo.image.zip?dl=0
>
>
Do you have the changes file, too?



>
>>
>> When not crashing it outputs this cherry tree.
>>
>> Thanks
>>
>> Hilaire
>>
>>
>
>

Re: [Pharo-users] Crash or locked VM

[stepharo]

thanks hilaire.

Stef

Le 5/1/16 22:11, Hilaire a écrit :

Hi,

I have a situation with a recursive Dr. Geo script where the image crash
or get locked (Can't hold on the image).
I tried with latest VM as detailed in the joined crash dump.

I did not get similar problem with other recursive script. So I may have
very special interaction between the objects, but I did not find out.

It may also be related to Morph because when instantiating first the
canvas and its window (2nd line of the script), then the rest of the
script, it does not crash.

The crashing image itself can be found there in case of usefulness
https://www.dropbox.com/s/rur8ayt8eon6mab/drgeo.image.zip?dl=0

When not crashing it outputs this cherry tree.

Thanks

Hilaire

Re: [Pharo-users] [Pharo-dev] [ann] gtdebugger in pharo 5.0

[Johan Fabry]

I second Torsten’s comment with regard to the use of space, I also think the 
original positioning of stack and code panes is more efficient.

> On Jan 8, 2016, at 14:28, Torsten Bergmann  wrote:
> 
> Hi,
> 
> with a moldable debugger we should (in the future) be able to support
> debugging also different/other programming languages/DSLs in Pharo :) 
> - although usually one does necessary have such a use case. So I guess
> GTInspector or other will be adopted to own needs more than GTDebugger. 
> 
> However:
> The only objection so far is that I dislike the order/size of the panes.
> The placement of the panes in GTDebugger (as for instance found in Moose)
> requires often to use the scrollbars of the pane showing the stack because
> of the text length. 
> 
> In GTDebugger the stack is at the top left, the source at the top right with 
> a common splitter beneath the two panes: therefore the height (depth) of the 
> stack pane is always the height of the code pane.
> When you have a long method to debug on the right much space is wasted for 
> a deep stack on the left although you might only be interested in a few top 
> frames.
> 
> Contrary when you have are interested in a deep/full stack and you increase 
> the
> height of the stack pane on the left you directly increase the height of the 
> code
> pane and for short methods you waste a lot of space in the source pane as 
> well.
> 
> This is much better solved with the positioning in the traditinal Debugger:
> - Stack 
> - Source
> - other 
> 
> So in my opinion We should preserve:
> 
>  - TOP:the stack at the top (using the full width of the window, so only 
> vertical scrolling
>has to be done to "roll" on the stack, no need for horizontal 
> scrolling as the area
>is wide enough)
>  - MIDDLE: the source code pane in the middle (also using the full width of 
> the window and there
>fore in alignment with code pane in the the usual tools like 
> Nautilus, change sorter, ...)
>  - BOTTON: one or more panel for inspection at the bottom
> 
> It would be OK for me if others like the new layout better - but at least 
> there should be an 
> option to support the traditional layout as well (or support pane 
> movemen/docking as in other IDEs) 
> 
> Also the debugger window in Moose wastes a lot of space/has unused space 
> within the 
> windows client are itself. For instance the splitters are very thick which 
> might be an issue of 
> the moose theme. 
>  
> Thanks
> T. 
> 
> Gesendet: Freitag, 08. Januar 2016 um 11:24 Uhr
> Von: "Tudor Girba" 
> An: "Pharo Development List" , "Moose-dev Moose 
> Dev" , "Any question about pharo is welcome" 
> 
> Betreff: [Pharo-dev] [ann] gtdebugger in pharo 5.0
> 
> Hi,
>  
> We are about to integrate in Pharo a new member of the Glamorous Toolkit: the 
> GTDebugger. As this is a significant change that might affect your workflow, 
> here is some background information to help you deal with the change.
>  
> First, you should know that the change is not irreversible and it is easily 
> possible to disabled the new debugger through a setting. However, please do 
> take the time to provide us feedback if something does not work out for you. 
> We want to know what can be improved and we try to react as fast as we can.
>  
> A practical change comes from the fact that the variables are manipulated 
> through a GTInspector, which makes it cheaper to maintain in the longer run.
>  
> 
>  While the first thing that will capture the attention is the default generic 
> interface, the real power comes from the moldable nature of the debugger. 
> Like all other GT tools, GTDebugger is also moldable by design. This means 
> that we can construct custom debuggers for specific libraries at small costs 
> (often measured in a couple of hundred lines of code).
>  
> 
>  
> Here is an introductory overview blog post that also includes some links for 
> further reading:
> http://www.humane-assessment.com/blog/gtdebugger-in-pharo/
>  
> Please let us know what you think.
>  
> Cheers,
> Doru
>  
>  
> --
> www.tudorgirba.com[http://www.tudorgirba.com]
> www.feenk.com[http://www.feenk.com]
> 
> "Beauty is where we see it."



---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry   -   http://pleiad.cl/~jfabry
PLEIAD and RyCh labs  -  Computer Science Department (DCC)  -  University of 
Chile

Re: [Pharo-users] [Pharo-dev] [ann] gtdebugger in pharo 5.0

[Torsten Bergmann]

Hi,

with a moldable debugger we should (in the future) be able to support
debugging also different/other programming languages/DSLs in Pharo :) 
- although usually one does necessary have such a use case. So I guess
GTInspector or other will be adopted to own needs more than GTDebugger. 

However:
The only objection so far is that I dislike the order/size of the panes.
The placement of the panes in GTDebugger (as for instance found in Moose)
requires often to use the scrollbars of the pane showing the stack because
of the text length. 

In GTDebugger the stack is at the top left, the source at the top right with 
a common splitter beneath the two panes: therefore the height (depth) of the 
stack pane is always the height of the code pane.
When you have a long method to debug on the right much space is wasted for 
a deep stack on the left although you might only be interested in a few top 
frames.

Contrary when you have are interested in a deep/full stack and you increase the
height of the stack pane on the left you directly increase the height of the 
code
pane and for short methods you waste a lot of space in the source pane as well.

This is much better solved with the positioning in the traditinal Debugger:
 - Stack 
 - Source
 - other 

So in my opinion We should preserve:

  - TOP:the stack at the top (using the full width of the window, so only 
vertical scrolling
has to be done to "roll" on the stack, no need for horizontal 
scrolling as the area
is wide enough)
  - MIDDLE: the source code pane in the middle (also using the full width of 
the window and there
fore in alignment with code pane in the the usual tools like 
Nautilus, change sorter, ...)
  - BOTTON: one or more panel for inspection at the bottom

It would be OK for me if others like the new layout better - but at least there 
should be an 
option to support the traditional layout as well (or support pane 
movemen/docking as in other IDEs) 

Also the debugger window in Moose wastes a lot of space/has unused space within 
the 
windows client are itself. For instance the splitters are very thick which 
might be an issue of 
the moose theme. 
 
Thanks
T. 

Gesendet: Freitag, 08. Januar 2016 um 11:24 Uhr
Von: "Tudor Girba" 
An: "Pharo Development List" , "Moose-dev Moose Dev" 
, "Any question about pharo is welcome" 

Betreff: [Pharo-dev] [ann] gtdebugger in pharo 5.0

Hi,
 
We are about to integrate in Pharo a new member of the Glamorous Toolkit: the 
GTDebugger. As this is a significant change that might affect your workflow, 
here is some background information to help you deal with the change.
 
First, you should know that the change is not irreversible and it is easily 
possible to disabled the new debugger through a setting. However, please do 
take the time to provide us feedback if something does not work out for you. We 
want to know what can be improved and we try to react as fast as we can.
 
A practical change comes from the fact that the variables are manipulated 
through a GTInspector, which makes it cheaper to maintain in the longer run.
 

 While the first thing that will capture the attention is the default generic 
interface, the real power comes from the moldable nature of the debugger. Like 
all other GT tools, GTDebugger is also moldable by design. This means that we 
can construct custom debuggers for specific libraries at small costs (often 
measured in a couple of hundred lines of code).
 

 
Here is an introductory overview blog post that also includes some links for 
further reading:
http://www.humane-assessment.com/blog/gtdebugger-in-pharo/
 
Please let us know what you think.
 
Cheers,
Doru
 
 
--
www.tudorgirba.com[http://www.tudorgirba.com]
www.feenk.com[http://www.feenk.com]

"Beauty is where we see it."


 

Re: [Pharo-users] Spec: Populating a playground with a particular content (was Re: Spec: Binding widgets how to)

[Johan Fabry]

Consider the error as reported! I should work on this text soon so I will fix 
it. If you find any more errors feel free to send me a mail.

> On Jan 8, 2016, at 12:43, Offray Vladimir Luna Cárdenas  
> wrote:
> 
> Thanks Johan,
> 
> This seems what I'm looking for. 
> 
> I running now the examples at the dynamic spec section and I have found an 
> error in Script 1.41: Setting up the sub widgets (pg 24 of current version) 
> in the first line, where it says " view label text: 'Packages:'." it should 
> be " view label label: 'Packages:'." There is any place where I can report 
> and/or correct such errors?
> 
> Cheers,
> 
> Offray
> 
> On 08/01/16 06:21, Johan Fabry wrote:
>> Hola,
>> 
>> it looks like what you want here is covered by dynamic spec. Have a look at 
>> the dynamic spec section in the Spec booklet (work in progress) 
>> https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgress/lastSuccessfulBuild/artifact/book-result/Spec/
>>  
>> 
>>  I think that it will answer your question.
>> 
>>> On Jan 7, 2016, at 22:36, Offray Vladimir Luna Cárdenas >> > wrote:
>>> 
>>>  How can I initializeWidgets with some kind of conditions depending on the 
>>> kind of selection I have done on the tree? 
>> 
>> 
>> 
>> ---> Save our in-boxes! http://emailcharter.org  
>> <---
>> 
>> Johan Fabry   -   http://pleiad.cl/~jfabry 
>> PLEIAD and RyCh labs  -  Computer Science Department (DCC)  -  University of 
>> Chile
>> 
> 



---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry   -   http://pleiad.cl/~jfabry
PLEIAD and RyCh labs  -  Computer Science Department (DCC)  -  University of 
Chile

Re: [Pharo-users] Spec: Populating a playground with a particular content (was Re: Spec: Binding widgets how to)

[Offray Vladimir Luna Cárdenas]

Thanks Johan,

This seems what I'm looking for.

I running now the examples at the dynamic spec section and I have found 
an error in Script 1.41: Setting up the sub widgets (pg 24 of current 
version) in the first line, where it says " view label text: 
'Packages:'." it should be " view label label: 'Packages:'." There is 
any place where I can report and/or correct such errors?


Cheers,

Offray

On 08/01/16 06:21, Johan Fabry wrote:

Hola,

it looks like what you want here is covered by dynamic spec. Have a 
look at the dynamic spec section in the Spec booklet (work in 
progress) 
https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgress/lastSuccessfulBuild/artifact/book-result/Spec/ 
I think that it will answer your question.


On Jan 7, 2016, at 22:36, Offray Vladimir Luna Cárdenas 
mailto:off...@riseup.net>> wrote:


How can I initializeWidgets with some kind of conditions depending on 
the kind of selection I have done on the tree?



---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry   - http://pleiad.cl/~jfabry 
PLEIAD and RyCh labs  -  Computer Science Department (DCC)  - 
 University of Chile

Re: [Pharo-users] gtdebugger in pharo 5.0

[Alexandre Bergel]

This is an excellent news! I have been waiting for that for long!
go go go!

Alexandre
-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



> On Jan 8, 2016, at 8:07 AM, Tudor Girba  wrote:
> 
> Hi,
> 
> We are about to integrate in Pharo a new member of the Glamorous Toolkit: the 
> GTDebugger. As this is a significant change that might affect your workflow, 
> here is some background information to help you deal with the change.
> 
> First, you should know that the change is not irreversible and it is easily 
> possible to disabled the new debugger through a setting. However, please do 
> take the time to provide us feedback if something does not work out for you. 
> We want to know what can be improved and we try to react as fast as we can.
> 
> A practical change comes from the fact that the variables are manipulated 
> through a GTInspector, which makes it cheaper to maintain in the longer run.
> 
> While the first thing that will capture the attention is the default generic 
> interface, the real power comes from the moldable nature of the debugger. 
> Like all other GT tools, GTDebugger is also moldable by design. This means 
> that we can construct custom debuggers for specific libraries at small costs 
> (often measured in a couple of hundred lines of code).
> 
> For example, the core configuration includes also the SUnit and the bytecode 
> debugger. These are around 150 lines of code. Here is how the bytecode 
> debugger looks like:
> 
> 
> 
> You can find more information in an introductory overview blog post that also 
> includes some links for further reading:
> http://www.humane-assessment.com/blog/gtdebugger-in-pharo/ 
> 
> 
> Please let us know what you think.
> 
> Cheers,
> Doru
> 
> 
> --
> www.tudorgirba.com 
> www.feenk.com
> 
> "What is more important: To be happy, or to make happy?"
> 

Re: [Pharo-users] [Moose-dev] Re: gtdebugger in pharo 5.0

[Andrei Chis]

On Fri, Jan 8, 2016 at 2:23 PM, Dimitris Chloupis 
wrote:

> is there any documentation about this ? or i just look at the relevant
> classes ?
>

Not really.  Now you'll need to look in UITheme>>styleContext:from:, but
I'll refactor that method shortly.



> On Fri, Jan 8, 2016 at 3:20 PM Andrei Chis 
> wrote:
>
>> On Fri, Jan 8, 2016 at 2:09 PM, Dimitris Chloupis 
>> wrote:
>>
>>> does the GTDebugger respect the pharo themes support or is it like
>>> GTSpotter ?
>>>
>>
>> It behaves just as GTInspector regrading the theme.  Just if you are
>> using a custom theme and want to have the coloring of the stack enabled you
>> need to provide the appropriate colors in your theme (styleContext:from:)
>>
>> Cheers,
>> Andrei
>>
>>
>>
>>>
>>> On Fri, Jan 8, 2016 at 1:08 PM Tudor Girba  wrote:
>>>
 Hi,

 We are about to integrate in Pharo a new member of the Glamorous
 Toolkit: the GTDebugger. As this is a significant change that might affect
 your workflow, here is some background information to help you deal
 with the change.

 First, you should know that the change is not irreversible and it is
 easily possible to disabled the new debugger through a setting. However,
 please do take the time to provide us feedback if something does not work
 out for you. We want to know what can be improved and we try to react as
 fast as we can.

 A practical change comes from the fact that the variables are
 manipulated through a GTInspector, which makes it cheaper to maintain in
 the longer run.

 While the first thing that will capture the attention is the default
 generic interface, the real power comes from the moldable nature of the
 debugger. Like all other GT tools, GTDebugger is also moldable by design.
 This means that we can construct custom debuggers for specific libraries at
 small costs (often measured in a couple of hundred lines of code).

 For example, the core configuration includes also the SUnit and the
 bytecode debugger. These are around 150 lines of code. Here is how the
 bytecode debugger looks like:



 You can find more information in an introductory overview blog post
 that also includes some links for further reading:

 http://www.humane-assessment.com/blog/gtdebugger-in-pharo/

 Please let us know what you think.

 Cheers,
 Doru


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

 "What is more important: To be happy, or to make happy?"

 ___
 Moose-dev mailing list
 moose-...@list.inf.unibe.ch
 https://www.list.inf.unibe.ch/listinfo/moose-dev

>>>
>>> ___
>>> Moose-dev mailing list
>>> moose-...@list.inf.unibe.ch
>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>
>>> ___
>> Moose-dev mailing list
>> moose-...@list.inf.unibe.ch
>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>
>

Re: [Pharo-users] [Moose-dev] Re: gtdebugger in pharo 5.0

[Dimitris Chloupis]

is there any documentation about this ? or i just look at the relevant
classes ?

On Fri, Jan 8, 2016 at 3:20 PM Andrei Chis 
wrote:

> On Fri, Jan 8, 2016 at 2:09 PM, Dimitris Chloupis 
> wrote:
>
>> does the GTDebugger respect the pharo themes support or is it like
>> GTSpotter ?
>>
>
> It behaves just as GTInspector regrading the theme.  Just if you are using
> a custom theme and want to have the coloring of the stack enabled you need
> to provide the appropriate colors in your theme (styleContext:from:)
>
> Cheers,
> Andrei
>
>
>
>>
>> On Fri, Jan 8, 2016 at 1:08 PM Tudor Girba  wrote:
>>
>>> Hi,
>>>
>>> We are about to integrate in Pharo a new member of the Glamorous
>>> Toolkit: the GTDebugger. As this is a significant change that might affect
>>> your workflow, here is some background information to help you deal
>>> with the change.
>>>
>>> First, you should know that the change is not irreversible and it is
>>> easily possible to disabled the new debugger through a setting. However,
>>> please do take the time to provide us feedback if something does not work
>>> out for you. We want to know what can be improved and we try to react as
>>> fast as we can.
>>>
>>> A practical change comes from the fact that the variables are
>>> manipulated through a GTInspector, which makes it cheaper to maintain in
>>> the longer run.
>>>
>>> While the first thing that will capture the attention is the default
>>> generic interface, the real power comes from the moldable nature of the
>>> debugger. Like all other GT tools, GTDebugger is also moldable by design.
>>> This means that we can construct custom debuggers for specific libraries at
>>> small costs (often measured in a couple of hundred lines of code).
>>>
>>> For example, the core configuration includes also the SUnit and the
>>> bytecode debugger. These are around 150 lines of code. Here is how the
>>> bytecode debugger looks like:
>>>
>>>
>>>
>>> You can find more information in an introductory overview blog post that
>>> also includes some links for further reading:
>>>
>>> http://www.humane-assessment.com/blog/gtdebugger-in-pharo/
>>>
>>> Please let us know what you think.
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>> --
>>> www.tudorgirba.com
>>> www.feenk.com
>>>
>>> "What is more important: To be happy, or to make happy?"
>>>
>>> ___
>>> Moose-dev mailing list
>>> moose-...@list.inf.unibe.ch
>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>
>>
>> ___
>> Moose-dev mailing list
>> moose-...@list.inf.unibe.ch
>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>
>> ___
> Moose-dev mailing list
> moose-...@list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev
>

Re: [Pharo-users] [Moose-dev] Re: gtdebugger in pharo 5.0

[Andrei Chis]

On Fri, Jan 8, 2016 at 2:09 PM, Dimitris Chloupis 
wrote:

> does the GTDebugger respect the pharo themes support or is it like
> GTSpotter ?
>

It behaves just as GTInspector regrading the theme.  Just if you are using
a custom theme and want to have the coloring of the stack enabled you need
to provide the appropriate colors in your theme (styleContext:from:)

Cheers,
Andrei



>
> On Fri, Jan 8, 2016 at 1:08 PM Tudor Girba  wrote:
>
>> Hi,
>>
>> We are about to integrate in Pharo a new member of the Glamorous Toolkit:
>> the GTDebugger. As this is a significant change that might affect your
>> workflow, here is some background information to help you deal with the
>> change.
>>
>> First, you should know that the change is not irreversible and it is
>> easily possible to disabled the new debugger through a setting. However,
>> please do take the time to provide us feedback if something does not work
>> out for you. We want to know what can be improved and we try to react as
>> fast as we can.
>>
>> A practical change comes from the fact that the variables are manipulated
>> through a GTInspector, which makes it cheaper to maintain in the longer run.
>>
>> While the first thing that will capture the attention is the default
>> generic interface, the real power comes from the moldable nature of the
>> debugger. Like all other GT tools, GTDebugger is also moldable by design.
>> This means that we can construct custom debuggers for specific libraries at
>> small costs (often measured in a couple of hundred lines of code).
>>
>> For example, the core configuration includes also the SUnit and the
>> bytecode debugger. These are around 150 lines of code. Here is how the
>> bytecode debugger looks like:
>>
>>
>>
>> You can find more information in an introductory overview blog post that
>> also includes some links for further reading:
>>
>> http://www.humane-assessment.com/blog/gtdebugger-in-pharo/
>>
>> Please let us know what you think.
>>
>> Cheers,
>> Doru
>>
>>
>> --
>> www.tudorgirba.com
>> www.feenk.com
>>
>> "What is more important: To be happy, or to make happy?"
>>
>> ___
>> Moose-dev mailing list
>> moose-...@list.inf.unibe.ch
>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>
>
> ___
> Moose-dev mailing list
> moose-...@list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev
>
>

Re: [Pharo-users] Spec: Populating a playground with a particular content (was Re: Spec: Binding widgets how to)

[Johan Fabry]

Hola,

it looks like what you want here is covered by dynamic spec. Have a look at the 
dynamic spec section in the Spec booklet (work in progress) 
https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgress/lastSuccessfulBuild/artifact/book-result/Spec/
 I think that it will answer your question.

> On Jan 7, 2016, at 22:36, Offray Vladimir Luna Cárdenas  
> wrote:
> 
>  How can I initializeWidgets with some kind of conditions depending on the 
> kind of selection I have done on the tree? 



---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry   -   http://pleiad.cl/~jfabry
PLEIAD and RyCh labs  -  Computer Science Department (DCC)  -  University of 
Chile

Re: [Pharo-users] Pine64

[Ben Coman]

I signed up for the PINE A64+ w/ 2GB SDRAM (March 2016).  I'm
interested in checking out the virtualization capabilities of the A53.

cheers -ben

On Fri, Jan 8, 2016 at 2:31 PM, John Pfersich  wrote:
> I've pre-ordered a Pine64 SBC. The write up says it's got a "1.2 Ghz
> Quad-Core ARM Cortex A53 64-Bit Processor. It has 64 and 32 Bit execution
> states for scalable high performance power – including a NEON Multimedia
> processing engine."
>
> Does anybody have an idea whether the vm for the raspberry pi will work with
> this new computer?
>
> This is what the ARM site says about the A53 processor:
>
> As well as running 64-bit applications, the Cortex-A53 seamlessly and
> efficiently runs legacy ARM 32-bit applications. It is highly scalable, from
> a single multi-core CPU cluster, to a dual-cluster big.LITTLE CPU subsystem
> in combination with the Cortex-A72or Cortex-A57 processor, to a
> multi-cluster enterprise system connected through AMBA® 5 CHI Coherent
> Interconnecttechnology. Full ARMv8-A support in a small and highly
> configurable package means that the Cortex-A53 is highly suited to a broad
> range of mobile, consumer, general purpose, and enterprise applications.
>
> Sent from my iPad
>
>
> Sent from my iPad