Re: [Pharo-users] brick/bloc examples missing FILOStack

[stepharo]

Bloc is a ***real*** Morph new kernel. Now we are lucky because it is 
powerful enough so that
we can render morphic morph inside itself. But Bloc has a new 
architecture rendering, event loop, and many more.


Stef


Le 1/6/15 08:09, Peter Uhnák a écrit :
Thanks, it seems to work now. I also had to switch to newly created 
"bloc" space. Why is that required? Why it wouldn't work also from 
"regular" Pharo space?


>> FILOStack

> Just wondering, isn't this a contradiction in terms ?
> A stack is by definition LIFO, a FILO structure is normally called a queue, 
no ?

queue is FIFO (first in, first out)
FILO technically should be the same as LIFO, only I have never heard 
someone say it in that order (since the top of the stack is the 
important bit, not the bottom).


Peter

On Mon, Jun 1, 2015 at 7:58 AM, Aliaksei Syrel > wrote:


Should work now, just update using Doru's script :)

Cheers,
Alex

On Mon, Jun 1, 2015 at 7:49 AM, Aliaksei Syrel
mailto:alex.sy...@gmail.com>> wrote:

Hi,

Oops, this kind of stack is from moose and not in pharo :)

Yes, better to use a queue - thanks!

Cheers,
Alex

On Jun 1, 2015 7:32 AM, "Sven Van Caekenberghe" mailto:s...@stfx.eu>> wrote:


> On 31 May 2015, at 23:15, Peter Uhnák mailto:i.uh...@gmail.com>> wrote:
>
> FILOStack

Just wondering, isn't this a contradiction in terms ?
A stack is by definition LIFO, a FILO structure is
normally called a queue, no ?

Re: [Pharo-users] brick/bloc examples missing FILOStack

[Sven Van Caekenberghe]

> On 01 Jun 2015, at 08:09, Peter Uhnák  wrote:
> 
> Thanks, it seems to work now. I also had to switch to newly created "bloc" 
> space. Why is that required? Why it wouldn't work also from "regular" Pharo 
> space?
> 
> >> FILOStack
> 
> > Just wondering, isn't this a contradiction in terms ?
> > A stack is by definition LIFO, a FILO structure is normally called a queue, 
> > no ?
> 
> queue is FIFO (first in, first out)

Right ;-)

> FILO technically should be the same as LIFO, only I have never heard someone 
> say it in that order (since the top of the stack is the important bit, not 
> the bottom).

Well, it was confusing ...

> Peter
> 
> On Mon, Jun 1, 2015 at 7:58 AM, Aliaksei Syrel  wrote:
> Should work now, just update using Doru's script :)
> 
> Cheers,
> Alex
> 
> On Mon, Jun 1, 2015 at 7:49 AM, Aliaksei Syrel  wrote:
> Hi,
> 
> Oops, this kind of stack is from moose and not in pharo :)
> 
> Yes, better to use a queue - thanks!
> 
> Cheers,
> Alex
> 
> On Jun 1, 2015 7:32 AM, "Sven Van Caekenberghe"  wrote:
> 
> > On 31 May 2015, at 23:15, Peter Uhnák  wrote:
> >
> > FILOStack
> 
> Just wondering, isn't this a contradiction in terms ?
> A stack is by definition LIFO, a FILO structure is normally called a queue, 
> no ?
> 
> 

Re: [Pharo-users] brick/bloc examples missing FILOStack

[PBKResearch]

Maybe a FILOStack has lots of very thin layers?
(http://en.wikipedia.org/wiki/Filo)

Best wishes

Peter Kenny

-Original Message-
From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of 
Sven Van Caekenberghe
Sent: 01 June 2015 08:13
To: Any question about pharo is welcome
Subject: Re: [Pharo-users] brick/bloc examples missing FILOStack


> On 01 Jun 2015, at 08:09, Peter Uhnák  wrote:
> 
> Thanks, it seems to work now. I also had to switch to newly created "bloc" 
> space. Why is that required? Why it wouldn't work also from "regular" Pharo 
> space?
> 
> >> FILOStack
> 
> > Just wondering, isn't this a contradiction in terms ?
> > A stack is by definition LIFO, a FILO structure is normally called a queue, 
> > no ?
> 
> queue is FIFO (first in, first out)

Right ;-)

> FILO technically should be the same as LIFO, only I have never heard someone 
> say it in that order (since the top of the stack is the important bit, not 
> the bottom).

Well, it was confusing ...

> Peter
> 
> On Mon, Jun 1, 2015 at 7:58 AM, Aliaksei Syrel  wrote:
> Should work now, just update using Doru's script :)
> 
> Cheers,
> Alex
> 
> On Mon, Jun 1, 2015 at 7:49 AM, Aliaksei Syrel  wrote:
> Hi,
> 
> Oops, this kind of stack is from moose and not in pharo :)
> 
> Yes, better to use a queue - thanks!
> 
> Cheers,
> Alex
> 
> On Jun 1, 2015 7:32 AM, "Sven Van Caekenberghe"  wrote:
> 
> > On 31 May 2015, at 23:15, Peter Uhnák  wrote:
> >
> > FILOStack
> 
> Just wondering, isn't this a contradiction in terms ?
> A stack is by definition LIFO, a FILO structure is normally called a queue, 
> no ?
> 
> 

Re: [Pharo-users] Slot questions

[tsl4]

As usual, though, a lot of interesting ideas emerge from this.

If we were to do documentation in a "Smalltalky" way, then what would it
look like?

Perhaps something like Doug Engelbart's NLS system, in outlines, but each
element of the outline would have an associative history to it. That would
mean breaking the process of description down to familiar component parts.
Selecting a version of the software would flow through the outline, calling
up the appropriate historical elements. That would enable comparative
documentation.

Or is it possible to find some kind of self documentation that would be
better than the useful but a little crude class comments?

It seems like such a basic thing to get right, but really very little work
has been done on it. 



--
View this message in context: 
http://forum.world.st/Slot-questions-tp4679631p4829738.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Issue with UDP Sockets

[Henrik Johansen]

> On 29 May 2015, at 7:24 , Sven Van Caekenberghe  wrote:
> 
> 
>> On 29 May 2015, at 18:23, Henrik Johansen  
>> wrote:
>> 
>>> 
>>> On 19 May 2015, at 11:01 , Sven Van Caekenberghe  wrote:
>>> 
>>> 
 On 19 May 2015, at 10:53, Udo Schneider  
 wrote:
 
> Did you look in all your package caches ?
 I did. Must have been a victim of cleaning ... but maybe TimeMachine has 
 something ... thanks for the reminder.
 
> If it is just a small example, like one class, maybe it could be
> added to the image, in which case it should indeed be a slice.
 The package was pretty simple. Basically only adding a few convenience 
 methods around Socket>>#setOption:value: . Still I think a usage example 
 in form of a class comment and test case might be appropriate. So unless 
 Multicast should be part of the base image I'll start with a separate 
 package first.
>>> 
>>> Since Socket is a fundamental part, and multicast is a key feature, I think 
>>> it would logical to move it to the image itself, with a test case.
>> 
>> It's not just multicast...
>> As a Socket newbie I recently spent longer than I care to admit learning you 
>> need to set SO_BROADCAST to true to not get a primitive failure when sending 
>> to a broadcast address. 
>> At least the comments in sqUnixSocket were entertaining!
>> 
>> Though I realize which options are actually supported depends on the VM, 
>> moving the list of potentially available cross-platform options (and a 
>> description of what they're used for) to a comment in the image (setOption: 
>> value: being the obvious location) might be a nice first step. 
> 
> Please help in the documentation effort.

I later found the option names are already documented in getOption:, but since 
that wasn't of much help (at least to me), I suggest introducing a more 
specific error than primitiveFailure.
Implementing that, the new test revealed a bug; empty UDP payloads will not be 
sent.

A suggested fix for both these issues can be found in 
SLICE-Issue-15657-Empty-UDP-packets-are-not-sent-HenrikSperreJohansen.1

Cheers,
Henry

[Pharo-users] SmalltalkHub permission denied

[Hilaire]

Hi,

I have permission denied from Monticello when saving a package to
SmalltalkHub repo.
Do I miss something?

Thanks

Hilaire

-- 
Dr. Geo
http://drgeo.eu
http://google.com/+DrgeoEu

[Pharo-users] Pharo 4 Image Freeze

[Craig Johnson]

Hi All,

I'm getting tired of Pharo 4 beta freezing.  It happens whenever a 
exception occurs while in the debugger.


Funny that I don't remember any of the Pharo 4 development images freezing.

Which image can I use that won't do this?

Craig

Re: [Pharo-users] SmalltalkHub permission denied

[Hilaire]

Le 01/06/2015 22:28, Hilaire a écrit :
> Hi,
>
> I have permission denied from Monticello when saving a package to
> SmalltalkHub repo.
> Do I miss something?
>
> Thanks
>
> Hilaire
>

...and I can login to the SmalltalkHub website

-- 
Dr. Geo
http://drgeo.eu
http://google.com/+DrgeoEu

Re: [Pharo-users] SmalltalkHub permission denied

[Esteban Lorenzano]

are you entering user and password?

> On 01 Jun 2015, at 22:30, Hilaire  wrote:
> 
> Le 01/06/2015 22:28, Hilaire a écrit :
>> Hi,
>> 
>> I have permission denied from Monticello when saving a package to
>> SmalltalkHub repo.
>> Do I miss something?
>> 
>> Thanks
>> 
>> Hilaire
>> 
> 
> ...and I can login to the SmalltalkHub website
> 
> -- 
> Dr. Geo
> http://drgeo.eu
> http://google.com/+DrgeoEu
> 
> 
> 

Re: [Pharo-users] Pharo 4 Image Freeze

[Esteban Lorenzano]

well… pharo4 is not a beta :)
weird that no one else reports same bug… can you give us a way to reproduce the 
problem? Instead telling you which image does not have a problem I was not 
aware, I would like more to give you a bugfix :)

Esteban

> On 01 Jun 2015, at 22:31, Craig Johnson  wrote:
> 
> 
> Hi All,
> 
> I'm getting tired of Pharo 4 beta freezing.  It happens whenever a exception 
> occurs while in the debugger.
> 
> Funny that I don't remember any of the Pharo 4 development images freezing.
> 
> Which image can I use that won't do this?
> 
> Craig
> 

Re: [Pharo-users] Pharo 4 Image Freeze

[Craig Johnson]

Sure thing.

To see the bug, file the code below into a clean image and run the 
example.  The when the debugger pops, step over each line in the 
method.  I'm doing this on a Windows OS.


Object subclass: #Cooler
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''
category: 'ImageFreeze'!

!Cooler methodsFor: 'as yet unclassified' stamp: 'CraigJohnson 6/1/2015 
23:31'!

runMe
|  a |
self halt.
self except.
a := 1.! !

"-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "!

Cooler class
instanceVariableNames: ''!

!Cooler class methodsFor: 'as yet unclassified' stamp: 'CraigJohnson 
6/1/2015 23:16'!

example
self new runMe ! !



On 2015/06/01 11:00 PM, Esteban Lorenzano wrote:

well… pharo4 is not a beta :)
weird that no one else reports same bug… can you give us a way to reproduce the 
problem? Instead telling you which image does not have a problem I was not 
aware, I would like more to give you a bugfix :)

Esteban


On 01 Jun 2015, at 22:31, Craig Johnson  wrote:


Hi All,

I'm getting tired of Pharo 4 beta freezing.  It happens whenever a exception 
occurs while in the debugger.

Funny that I don't remember any of the Pharo 4 development images freezing.

Which image can I use that won't do this?

Craig

Re: [Pharo-users] Pharo 4 Image Freeze

[Nicolai Hess]

2015-06-01 23:44 GMT+02:00 Craig Johnson :

> Sure thing.
>
> To see the bug, file the code below into a clean image and run the
> example.  The when the debugger pops, step over each line in the method.
> I'm doing this on a Windows OS.
>
> Object subclass: #Cooler
> instanceVariableNames: ''
> classVariableNames: ''
> poolDictionaries: ''
> category: 'ImageFreeze'!
>
> !Cooler methodsFor: 'as yet unclassified' stamp: 'CraigJohnson 6/1/2015
> 23:31'!
> runMe
> |  a |
> self halt.
> self except.
> a := 1.! !
>
> "-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "!
>
> Cooler class
> instanceVariableNames: ''!
>
> !Cooler class methodsFor: 'as yet unclassified' stamp: 'CraigJohnson
> 6/1/2015 23:16'!
> example
> self new runMe ! !
>
>
This worked until pharo 40245
-> it looks like phase4 in issue
11996 
Wrong exception handler problem

introduced this behavior.






>
>
>
> On 2015/06/01 11:00 PM, Esteban Lorenzano wrote:
>
>> well… pharo4 is not a beta :)
>> weird that no one else reports same bug… can you give us a way to
>> reproduce the problem? Instead telling you which image does not have a
>> problem I was not aware, I would like more to give you a bugfix :)
>>
>> Esteban
>>
>>  On 01 Jun 2015, at 22:31, Craig Johnson  wrote:
>>>
>>>
>>> Hi All,
>>>
>>> I'm getting tired of Pharo 4 beta freezing.  It happens whenever a
>>> exception occurs while in the debugger.
>>>
>>> Funny that I don't remember any of the Pharo 4 development images
>>> freezing.
>>>
>>> Which image can I use that won't do this?
>>>
>>> Craig
>>>
>>>
>>
>
>

Re: [Pharo-users] SmalltalkHub permission denied

[Ben Coman]

On Tue, Jun 2, 2015 at 4:28 AM, Hilaire  wrote:
> I have permission denied from Monticello when saving a package to
> SmalltalkHub repo.
> Do I miss something?

Can you copy your repo definition (of course minus the password :)
cheers -ben

[Pharo-users] Visualizing a repository tree

[Offray Vladimir Luna Cárdenas]

Hi all,

I had asked a similar question before with no much advances, but today I 
made a discovery that can improve the things a lot: how to export 
timeline data as structured JSON [1] (and of course this open the 
possibility to work with it on Pharo). Now I would like to graph the 
data as a tree with forks, merges and dates and authors of commits. I 
have seen chronia, but seems overkill for this feature (and is 
integrated with CVS only).


[1] 
http://stackoverflow.com/questions/30577090/how-to-export-fossil-scm-timeline-to-another-format/30580043#30580043


As usual, any pointer on how to get this going will be greatly 
appreciated and I will give feedback to the community on how to do it.


Cheers,

Offray

Re: [Pharo-users] Visualizing a repository tree

[Offray Vladimir Luna Cárdenas]

Hi,

On a closer detail, seems that [1] contains the starting point I'm 
looking for. I'll keep you posted and of course any other approach will 
be listened.


[1] 
https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Roassal/0104-Roassal.html


Cheers,

Offray

On 01/06/15 22:04, Offray Vladimir Luna Cárdenas wrote:

Hi all,

I had asked a similar question before with no much advances, but today 
I made a discovery that can improve the things a lot: how to export 
timeline data as structured JSON [1] (and of course this open the 
possibility to work with it on Pharo). Now I would like to graph the 
data as a tree with forks, merges and dates and authors of commits. I 
have seen chronia, but seems overkill for this feature (and is 
integrated with CVS only).


[1] 
http://stackoverflow.com/questions/30577090/how-to-export-fossil-scm-timeline-to-another-format/30580043#30580043


As usual, any pointer on how to get this going will be greatly 
appreciated and I will give feedback to the community on how to do it.


Cheers,

Offray

[Pharo-users] Pharo Image Freeze (was Pharo 4 Image Freeze)

[Craig Johnson]

2015-06-01 23:44 GMT+02:00*Nicolai Hess*  nicolaihess at web.de  
:
/
/> This worked until pharo 40245

-> it looks like phase4 in issue
11996 
Wrong exception handler problem

introduced this behaviour.



Thanks Nicolai.  I see that it's still an issue in Pharo 5.
I can try to create a new bug report if that Ok with the community.

Craig

Re: [Pharo-users] Slot questions

[Marcus Denker]

Yes, indeed… Knuth’s Literary Programming was one radical
(yet very static and Book-Like) try.

We added the tutorials, that is already better than just the class comment,
but they are then not “connected” with the code… 

So indeed: a lot of open space for research + practical improvements.

For Slots I will stay very old fashioned and write a Tutorial.

Marcus

> On 01 Jun 2015, at 11:44, tsl4  wrote:
> 
> As usual, though, a lot of interesting ideas emerge from this.
> 
> If we were to do documentation in a "Smalltalky" way, then what would it
> look like?
> 
> Perhaps something like Doug Engelbart's NLS system, in outlines, but each
> element of the outline would have an associative history to it. That would
> mean breaking the process of description down to familiar component parts.
> Selecting a version of the software would flow through the outline, calling
> up the appropriate historical elements. That would enable comparative
> documentation.
> 
> Or is it possible to find some kind of self documentation that would be
> better than the useful but a little crude class comments?
> 
> It seems like such a basic thing to get right, but really very little work
> has been done on it. 
> 
> 
> 
> --
> View this message in context: 
> http://forum.world.st/Slot-questions-tp4679631p4829738.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>