[Pharo-dev] [JOB] Pharo Engineer, IoT

[Marcus Denker]

Engineer Position 1 Year
===

INRIA RMoD and the Pharo Consortium are looking for a full-time engineer for 
helping with developing Pharo.

The focus of this job is "Pharo on embedded and mobile devices for the internet 
of things".

- Embedded Pharo on ARM
The currently available class of ARM devices (BeagleBone, Raspberry PI) are a 
very interesting platform for Pharo.
The engineer should strengthen the existing efforts to get Pharo working on 
these platforms.

- Pharo on Android 
Improve the support of Android devices. With Pharo6, we will migrate to a 
complete new design and implementation of 
UI, Windowing and graphics. The engineer will work on making these features 
available on Android devices. 


- Pharo itself
The engineer is expected to be actively involved in helping to improve the 
infrastructure that the Pharo community used
(CI server for continues integration, interplay with issue tracking) and to 
actively help with day-to-day bug fixing.


We are looking for a candidate with some prior experience with Pharo

- Knowledge in Dynamic Languages
- Experience with mobile development is a plus
- English

Work in a research lab, but no paper writing, no teaching, no administration. 
In addition:

- centrally located (one hour from Paris, 1h20 from London, 35 min from 
Brussels)
- try a lot of good beer (our office is just 10km from the border to 
Belgium)
- Program with Pharo all day!

Lille is an active city but not expensive (lot of students...), centrally 
located with good connections
by train to everywhere (including CDG and Brussels airports).


Duration: 12 month
Starting date: as soon as possible (Spring 2016)
Salary: 2600-3200 euros brut / month, depending on experience
Location: Lille (no remote job possible)
   
More about
  Pharo: http://www.pharo.org
  INRIA RMOD: http://rmod.lille.inria.fr
  INRIA Lille: http://www.inria.fr/lille/
  INRIA in General: http://www.inria.fr
  Lille: http://en.wikipedia.org/wiki/Lille
 http://wikitravel.org/en/Lille

Do not hesitate to contact us for more information.

[Pharo-dev] [JOB] Pharo Engineer, Infrastructure

[Marcus Denker]

Engineer Position 1 year + 1 year
==

INRIA RMoD and the Pharo Consortium are looking for a full-time engineer for 
helping with developing 
Pharo and the infrastructure around it.

The focus of this job is the infrastructure that Pharo provides to external 
projects as well as the
infrastructure we use to develop Pharo itself.

- Infrastructure for external projects
Pharo is used in many contexts: an ever growing number of frameworks are 
contributed by the community. Pharo already
provides CI infrastructure, but what is missing is the automatic check of 
collections of frameworks and libraries.
We want to provides validated "distributions" focussing on certain tasks, for 
example Pharo for Web development.

- Pharo and Git
Pharo has some support for using Git. The goal is to improve the support of git 
and other versioning systems.

- Pharo itself
The engineer is expected to be actively involved in helping to improve the 
infrastructure that the Pharo community uses
(CI server for continues integration, interplay with issue tracking) and to 
actively help with day-to-day bug fixing.

We are looking for a candidate with prior experience with Pharo and possibly 
some background in continuous integration:

- Knowledge in Dynamic Languages
- Continuous integration and deployment
- English

Work in a research lab, but no paper writing, no teaching, no administration. 
In addition:

- Centrally located (one hour from Paris, 1h20 from London, 35 min from 
Brussels)
- Try a lot of good beer (our office is just 10km from the border to 
Belgium)
- Program with Pharo all day!

Lille is an active city but not expensive (lot of students...), centrally 
located with good connections
by train to everywhere (including CDG and Brussels airports).


Duration: 12 + 12 months
Starting date: Feb or March 2016
Salary: 2600-3200 euros brut / month, depending on experience
Location: Lille (no remote job possible)
   
More about
  Pharo: http://www.pharo.org
  INRIA RMOD: http://rmod.lille.inria.fr
  INRIA Lille: http://www.inria.fr/lille/
  INRIA in General: http://www.inria.fr
  Lille: http://en.wikipedia.org/wiki/Lille
 http://wikitravel.org/en/Lille

Do not hesitate to contact us for more information.

Re: [Pharo-dev] Unicode Support

[Eliot Miranda]

Hi Todd,

> On Dec 11, 2015, at 12:57 PM, Todd Blanchard  wrote:
> 
> 
>> On Dec 11, 2015, at 12:19, EuanM  wrote:
>> 
>> "If it hasn't already been said, please do not conflate Unicode and
>> UTF-8. I think that would be a recipe for
>> a high P.I.T.A. factor."  --Richard Sargent
> 
> Well, yes. But  I think you guys are making this way too hard.
> 
> A unicode character is an abstract idea - for instance the letter 'a'.
> The letter 'a' has a code point - its the number 97.  How the number 97 is 
> represented in the computer is irrelevant.
> 
> Now we get to transfer encodings.  These are UTF8, UTF16, etc  A transfer 
> encoding specifies the binary representation of the sequence of code points.
> 
> UTF8 is a variable length byte encoding.  You read it one byte at a time, 
> aggregating byte sequences to 'code points'.  ByteArray would be an excellent 
> choice as a superclass but it must be understood that #at: or #at:put refers 
> to a byte, not a character.  If you want characters, you have to start at the 
> beginning and process it sequentially, like a stream (if working in the ASCII 
> domain - you can generally 'cheat' this a bit).  A C representation would be 
> char utf8[]
> 
> UTF16 is also a variable length encoding of two byte quantities - what C used 
> to call a 'short int'.  You process it in two byte chunks instead of one byte 
> chunks.  Like UTF8, you must read it sequentially to interpret the 
> characters.  #at and #at:put: would necessarily refer to byte pairs and not 
> characters.  A C representation would be short utf16[];  It would also to 50% 
> space inefficient for ASCII - which is normally the bulk of your text.
> 
> Realistically, you need exactly one in-memory format and stream 
> readers/writers that can convert (these are typically table driven state 
> machines).  My choice would be UTF8 for the internal memory format and the 
> ability to read and write from UTF8 to UTF16.  
> 
> But I stress again...strings don't really need indexability as much as you 
> think and neither UTF8 nor UTF16 provide this property anyhow as they are 
> variable length encodings.  I don't see any sensible reason to have more than 
> one in-memory binary format in the image.

The only reasons are space and time.  If a string only contains code points in 
the range 0-255 there's no point in squandering 4 bytes per code point (same 
goes for 0-65535).  Further, if in some application interchange is more 
important than random access it may make sense in performance grounds to use 
utf-8 directly.

Again, Smalltalk's dynamic typing makes it easy to have one's cake and eat it 
too.

> My $0.02c

_,,,^..^,,,_ (phone)

> 
>> I agree. :-)
>> 
>> Regarding UTF-16, I just want to be able to export to, and receive
>> from, Windows (and any other platforms using UTF-16 as their native
>> character representation).
>> 
>> Windows will always be able to accept UTF-16.  All Windows apps *might
>> well* export UTF-16.  There may be other platforms which use UTF-16 as
>> their native format.  I'd just like to be able to cope with those
>> situations.  Nothing more.
>> 
>> All this is requires is a Utf16String class that has an asUtf8String
>> method (and any other required conversion methods). 
> 

Re: [Pharo-dev] Some GT tool for this?

[Andrei Chis]

On Fri, Dec 11, 2015 at 8:10 PM, Mariano Martinez Peck <
marianop...@gmail.com> wrote:

>
>
> On Fri, Dec 11, 2015 at 4:01 PM, Andrei Chis 
> wrote:
>
>> You can add the two methods below. Then when you open Spotter on a
>> package you can also search through it's history.
>> This will trigger an update if the history is not present, but Spotter
>> will still respond quite fast.
>>
>> You can also dive in a MCVersionInfo to see its ancestors.
>>
>> RPackage>>spotterHistoryFor: aStep
>> 
>> aStep listProcessor
>> title: 'History';
>> allCandidates: [ |ancestry|
>> ancestry := (MCWorkingCopy allManagers detect: [:each | each packageName
>> = self name]) ancestry.
>> ancestry withBreadthFirstAncestors select: [:each | each isKindOf:
>> MCVersionInfo] ];
>> candidatesLimit: 50;
>> itemName: [ :each | each name, ' - ', each message ];
>> filter: GTFilterSubstrings
>>
>> MCVersionInfo>>spotterPreviewCodeIn: aComposite
>> 
>> aComposite text
>> title: 'Summary';
>> display: [
>> self summaryHeader, String cr,
>> 'Message:', String cr, self message ];
>> entity: self.
>> Cheers,
>> Andrei
>>
>>
> Wow I send the other email before reading this one. This is much
> better hahahaha.
> Could these 2 extensions be incorporated as part of GT for further Pharo
> releases?
>  I don't like the #isKindOf:   but it happened to me that if I sent
> #allAncestors I would not get the latest commits.
> And the #isKindOf:   is because otherwise the first elements
> are MCLazyVersionInfo.
> I am not sure. Maybe someone with better understanding of MC could tell us
> the correct code.
>

Let's see if we can find a cleaner way.
If now I'll push them like this :)

Cheers,
Andrei


>
> Thanks!
>
>
>
>>
>> On Fri, Dec 11, 2015 at 4:52 PM, Eliot Miranda 
>> wrote:
>>
>>> Hi Mariano,
>>>
>>> for this in Squeak I added a simple menu pick to the Monticello
>>> Browser's package list menu called "search history" which opens up a
>>> workspace containing the entire history as a flat string.  I then just
>>> search using ctrl-f.  You can find it in a current squeak trunk image.
>>>
>>> _,,,^..^,,,_ (phone)
>>>
>>> On Dec 10, 2015, at 9:12 AM, Mariano Martinez Peck <
>>> marianop...@gmail.com> wrote:
>>>
>>> How many times have you tried to search a string as a comment of a
>>> commit in all the history? Myself: many many times. I know we need much
>>> better tools for that, store the history in a another way, provide a nicer
>>> API, etc etc. And I know there were topics about that.
>>>
>>> However, I would deeply appreciate a very short term solution for ease
>>> that. The model side is as simple as this:
>>>
>>> | packageName ancestry anscestors substring |
>>> packageName := 'MyPackageXX'.
>>> substring := 'whatever I want to search'.
>>> ancestry := (MCWorkingCopy allManagers detect: [:each | each packageName
>>> = packageName] ) ancestry.
>>> anscestors := ancestry withBreadthFirstAncestors select: [:each | each
>>> isKindOf: MCVersionInfo].
>>> anscestors select: [ :each | each message includesSubstring: substring ]
>>>
>>> Do you think it's worth a simple UI tool? Custom inspector of MCAncestry?
>>>
>>> Cheers,
>>>
>>>
>>> --
>>> Mariano
>>> http://marianopeck.wordpress.com
>>>
>>>
>>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>

Re: [Pharo-dev] Some GT tool for this?

[Mariano Martinez Peck]

On Fri, Dec 11, 2015 at 4:01 PM, Andrei Chis 
wrote:

> You can add the two methods below. Then when you open Spotter on a package
> you can also search through it's history.
> This will trigger an update if the history is not present, but Spotter
> will still respond quite fast.
>
> You can also dive in a MCVersionInfo to see its ancestors.
>
> RPackage>>spotterHistoryFor: aStep
> 
> aStep listProcessor
> title: 'History';
> allCandidates: [ |ancestry|
> ancestry := (MCWorkingCopy allManagers detect: [:each | each packageName =
> self name]) ancestry.
> ancestry withBreadthFirstAncestors select: [:each | each isKindOf:
> MCVersionInfo] ];
> candidatesLimit: 50;
> itemName: [ :each | each name, ' - ', each message ];
> filter: GTFilterSubstrings
>
> MCVersionInfo>>spotterPreviewCodeIn: aComposite
> 
> aComposite text
> title: 'Summary';
> display: [
> self summaryHeader, String cr,
> 'Message:', String cr, self message ];
> entity: self.
> Cheers,
> Andrei
>
>
Wow I send the other email before reading this one. This is much better
hahahaha.
Could these 2 extensions be incorporated as part of GT for further Pharo
releases?
 I don't like the #isKindOf:   but it happened to me that if I sent
#allAncestors I would not get the latest commits.
And the #isKindOf:   is because otherwise the first elements
are MCLazyVersionInfo.
I am not sure. Maybe someone with better understanding of MC could tell us
the correct code.

Thanks!



>
> On Fri, Dec 11, 2015 at 4:52 PM, Eliot Miranda 
> wrote:
>
>> Hi Mariano,
>>
>> for this in Squeak I added a simple menu pick to the Monticello
>> Browser's package list menu called "search history" which opens up a
>> workspace containing the entire history as a flat string.  I then just
>> search using ctrl-f.  You can find it in a current squeak trunk image.
>>
>> _,,,^..^,,,_ (phone)
>>
>> On Dec 10, 2015, at 9:12 AM, Mariano Martinez Peck 
>> wrote:
>>
>> How many times have you tried to search a string as a comment of a commit
>> in all the history? Myself: many many times. I know we need much better
>> tools for that, store the history in a another way, provide a nicer API,
>> etc etc. And I know there were topics about that.
>>
>> However, I would deeply appreciate a very short term solution for ease
>> that. The model side is as simple as this:
>>
>> | packageName ancestry anscestors substring |
>> packageName := 'MyPackageXX'.
>> substring := 'whatever I want to search'.
>> ancestry := (MCWorkingCopy allManagers detect: [:each | each packageName
>> = packageName] ) ancestry.
>> anscestors := ancestry withBreadthFirstAncestors select: [:each | each
>> isKindOf: MCVersionInfo].
>> anscestors select: [ :each | each message includesSubstring: substring ]
>>
>> Do you think it's worth a simple UI tool? Custom inspector of MCAncestry?
>>
>> Cheers,
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>>
>


-- 
Mariano
http://marianopeck.wordpress.com

Re: [Pharo-dev] Some GT tool for this?

[Mariano Martinez Peck]

On Fri, Dec 11, 2015 at 12:52 PM, Eliot Miranda 
wrote:

> Hi Mariano,
>
> for this in Squeak I added a simple menu pick to the Monticello
> Browser's package list menu called "search history" which opens up a
> workspace containing the entire history as a flat string.  I then just
> search using ctrl-f.  You can find it in a current squeak trunk image.
>
>
Hi Eliot,

Yes, I was thinking the same.  In the meanwhile, I did this extension:

MCWorkingCopy >> gtInspectorIrIn: composite

composite text
title: 'History';
display: [ :workingCopy |
TimeProfiler spyOn: [| stream versionInfos |
stream := String new writeStream.
versionInfos := workingCopy ancestry withBreadthFirstAncestors select:
[:each | each isKindOf: MCVersionInfo].
versionInfos do: [ :each |
stream nextPutAll: each summary; cr; cr.
].
stream contents.].
]

And then I can use the regular cmd+f to search the string.
But I have to manually inspect the package doing something like:


(MCWorkingCopy allManagers detect: [:each | each packageName =
'MyPackage']) inspect.




> _,,,^..^,,,_ (phone)
>
> On Dec 10, 2015, at 9:12 AM, Mariano Martinez Peck 
> wrote:
>
> How many times have you tried to search a string as a comment of a commit
> in all the history? Myself: many many times. I know we need much better
> tools for that, store the history in a another way, provide a nicer API,
> etc etc. And I know there were topics about that.
>
> However, I would deeply appreciate a very short term solution for ease
> that. The model side is as simple as this:
>
> | packageName ancestry anscestors substring |
> packageName := 'MyPackageXX'.
> substring := 'whatever I want to search'.
> ancestry := (MCWorkingCopy allManagers detect: [:each | each packageName =
> packageName] ) ancestry.
> anscestors := ancestry withBreadthFirstAncestors select: [:each | each
> isKindOf: MCVersionInfo].
> anscestors select: [ :each | each message includesSubstring: substring ]
>
> Do you think it's worth a simple UI tool? Custom inspector of MCAncestry?
>
> Cheers,
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>


-- 
Mariano
http://marianopeck.wordpress.com

Re: [Pharo-dev] Some GT tool for this?

[Andrei Chis]

You can add the two methods below. Then when you open Spotter on a package
you can also search through it's history.
This will trigger an update if the history is not present, but Spotter will
still respond quite fast.

You can also dive in a MCVersionInfo to see its ancestors.

RPackage>>spotterHistoryFor: aStep

aStep listProcessor
title: 'History';
allCandidates: [ |ancestry|
ancestry := (MCWorkingCopy allManagers detect: [:each | each packageName =
self name]) ancestry.
ancestry withBreadthFirstAncestors select: [:each | each isKindOf:
MCVersionInfo] ];
candidatesLimit: 50;
itemName: [ :each | each name, ' - ', each message ];
filter: GTFilterSubstrings

MCVersionInfo>>spotterPreviewCodeIn: aComposite

aComposite text
title: 'Summary';
display: [
self summaryHeader, String cr,
'Message:', String cr, self message ];
entity: self.
Cheers,
Andrei



On Fri, Dec 11, 2015 at 4:52 PM, Eliot Miranda 
wrote:

> Hi Mariano,
>
> for this in Squeak I added a simple menu pick to the Monticello
> Browser's package list menu called "search history" which opens up a
> workspace containing the entire history as a flat string.  I then just
> search using ctrl-f.  You can find it in a current squeak trunk image.
>
> _,,,^..^,,,_ (phone)
>
> On Dec 10, 2015, at 9:12 AM, Mariano Martinez Peck 
> wrote:
>
> How many times have you tried to search a string as a comment of a commit
> in all the history? Myself: many many times. I know we need much better
> tools for that, store the history in a another way, provide a nicer API,
> etc etc. And I know there were topics about that.
>
> However, I would deeply appreciate a very short term solution for ease
> that. The model side is as simple as this:
>
> | packageName ancestry anscestors substring |
> packageName := 'MyPackageXX'.
> substring := 'whatever I want to search'.
> ancestry := (MCWorkingCopy allManagers detect: [:each | each packageName =
> packageName] ) ancestry.
> anscestors := ancestry withBreadthFirstAncestors select: [:each | each
> isKindOf: MCVersionInfo].
> anscestors select: [ :each | each message includesSubstring: substring ]
>
> Do you think it's worth a simple UI tool? Custom inspector of MCAncestry?
>
> Cheers,
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>

Re: [Pharo-dev] Why Zinc servers implemented with options dictionary instead of normal instance variables?

[Dimitris Chloupis]

easy to answer that 

initialize their values , make sure you use sensible names for the
dictionary entries. documented and still no image pollution.

On Fri, Dec 11, 2015 at 8:02 PM Sven Van Caekenberghe  wrote:

>
> > On 11 Dec 2015, at 17:45, Dimitris Chloupis 
> wrote:
> >
> > the real question here is why pharo classes have the tendency to output
> so much data through individual methods when a single method returning a
> dictionary or any other collection would make much more sense and would be
> far more flexible and elegant to deal with. Unnecessary pollution of the
> image with methods.
>
> Hmm, I wouldn't call that pollution. I think it is a form of
> documentation. The options are a good example of that. We could add an
> accessor for #options, just returning the dictionary that is now
> encapsulated, and then delete all the nice accessors, like
> #useGzipCompressionAndChunking. With the accessors gone, how would you
> discover or see what is available ? Where should the existing options be
> documented ? Now you can browse them in the options protocol, all in one
> place, one by one, with documentation and clearly visible defaults.
>
> > On Fri, Dec 11, 2015 at 6:11 PM Sven Van Caekenberghe 
> wrote:
> >
> > > On 11 Dec 2015, at 16:28, Denis Kudriashov 
> wrote:
> > >
> > >
> > > 2015-12-11 15:51 GMT+01:00 Sven Van Caekenberghe :
> > > Because there are many options, 10, 20, and at that time slots were
> not yet available.
> > >
> > > Is not it is same case as class with 20 variables which always smell
> bad?
> >
> > That's why it is a dictionary ;-)
> >
> > Can't an object have 10, 20 or more properties (independent of how they
> are stored) ?
> >
> > You could of course delegate options to another sub object but why ?
> >
> > Apart from that, I do agree that both the main server object and the
> main client object are too big, they are like big interfaces to a lot of
> related functionality. The objects behind them, the ones in Zinc-HTTP-Core,
> are much more single purpose and simpler.
>
>
>

Re: [Pharo-dev] Why Zinc servers implemented with options dictionary instead of normal instance variables?

[Sven Van Caekenberghe]

> On 11 Dec 2015, at 17:45, Dimitris Chloupis  wrote:
> 
> the real question here is why pharo classes have the tendency to output so 
> much data through individual methods when a single method returning a 
> dictionary or any other collection would make much more sense and would be 
> far more flexible and elegant to deal with. Unnecessary pollution of the 
> image with methods. 

Hmm, I wouldn't call that pollution. I think it is a form of documentation. The 
options are a good example of that. We could add an accessor for #options, just 
returning the dictionary that is now encapsulated, and then delete all the nice 
accessors, like #useGzipCompressionAndChunking. With the accessors gone, how 
would you discover or see what is available ? Where should the existing options 
be documented ? Now you can browse them in the options protocol, all in one 
place, one by one, with documentation and clearly visible defaults.

> On Fri, Dec 11, 2015 at 6:11 PM Sven Van Caekenberghe  wrote:
> 
> > On 11 Dec 2015, at 16:28, Denis Kudriashov  wrote:
> >
> >
> > 2015-12-11 15:51 GMT+01:00 Sven Van Caekenberghe :
> > Because there are many options, 10, 20, and at that time slots were not yet 
> > available.
> >
> > Is not it is same case as class with 20 variables which always smell bad?
> 
> That's why it is a dictionary ;-)
> 
> Can't an object have 10, 20 or more properties (independent of how they are 
> stored) ?
> 
> You could of course delegate options to another sub object but why ?
> 
> Apart from that, I do agree that both the main server object and the main 
> client object are too big, they are like big interfaces to a lot of related 
> functionality. The objects behind them, the ones in Zinc-HTTP-Core, are much 
> more single purpose and simpler.

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

[GitHub]

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

[Pharo-dev] [pharo-project/pharo-core] 950ae8: 50495

[GitHub]

  Branch: refs/heads/5.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 950ae8914e92c7b765a8e39656335c8140d8c938
  
https://github.com/pharo-project/pharo-core/commit/950ae8914e92c7b765a8e39656335c8140d8c938
  Author: Jenkins Build Server 
  Date:   2015-12-11 (Fri, 11 Dec 2015)

  Changed paths:
M Morphic-Widgets-Pluggable.package/PluggableListMorph.class/instance/debug 
and other/userString.st
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
scripts/script50494.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
scripts/script50495.st
R ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
updates/update50494.st
A ScriptLoader50.package/ScriptLoader.class/instance/pharo - 
updates/update50495.st
M 
ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st

  Log Message:
  ---
  50495
17226 PluggableListMorph>>#userString should return one string
https://pharo.fogbugz.com/f/cases/17226

http://files.pharo.org/image/50/50495.zip

Re: [Pharo-dev] Why Zinc servers implemented with options dictionary instead of normal instance variables?

[Dimitris Chloupis]

the real question here is why pharo classes have the tendency to output so
much data through individual methods when a single method returning a
dictionary or any other collection would make much more sense and would be
far more flexible and elegant to deal with. Unnecessary pollution of the
image with methods.

On Fri, Dec 11, 2015 at 6:11 PM Sven Van Caekenberghe  wrote:

>
> > On 11 Dec 2015, at 16:28, Denis Kudriashov  wrote:
> >
> >
> > 2015-12-11 15:51 GMT+01:00 Sven Van Caekenberghe :
> > Because there are many options, 10, 20, and at that time slots were not
> yet available.
> >
> > Is not it is same case as class with 20 variables which always smell bad?
>
> That's why it is a dictionary ;-)
>
> Can't an object have 10, 20 or more properties (independent of how they
> are stored) ?
>
> You could of course delegate options to another sub object but why ?
>
> Apart from that, I do agree that both the main server object and the main
> client object are too big, they are like big interfaces to a lot of related
> functionality. The objects behind them, the ones in Zinc-HTTP-Core, are
> much more single purpose and simpler.
>

Re: [Pharo-dev] Why Zinc servers implemented with options dictionary instead of normal instance variables?

[Sven Van Caekenberghe]

> On 11 Dec 2015, at 16:28, Denis Kudriashov  wrote:
> 
> 
> 2015-12-11 15:51 GMT+01:00 Sven Van Caekenberghe :
> Because there are many options, 10, 20, and at that time slots were not yet 
> available.
> 
> Is not it is same case as class with 20 variables which always smell bad? 

That's why it is a dictionary ;-)

Can't an object have 10, 20 or more properties (independent of how they are 
stored) ?

You could of course delegate options to another sub object but why ?

Apart from that, I do agree that both the main server object and the main 
client object are too big, they are like big interfaces to a lot of related 
functionality. The objects behind them, the ones in Zinc-HTTP-Core, are much 
more single purpose and simpler.

Re: [Pharo-dev] Hook "WACurrentRequestContext" into debugger?

[Mariano Martinez Peck]

On Fri, Dec 11, 2015 at 12:51 PM, Max Leske  wrote:

>
> On 11 Dec 2015, at 16:39, Mariano Martinez Peck 
> wrote:
>
>
>
> On Fri, Dec 11, 2015 at 12:25 PM, Max Leske  wrote:
>
>>
>> On 10 Dec 2015, at 21:21, Mariano Martinez Peck 
>> wrote:
>>
>>
>>
>> On Thu, Dec 10, 2015 at 4:12 PM, Mariano Martinez Peck <
>> marianop...@gmail.com> wrote:
>>
>>>
>>>
>>> On Thu, Dec 10, 2015 at 7:27 AM, Max Leske  wrote:
>>>

 On 07 Dec 2015, at 17:17, Mariano Martinez Peck 
 wrote:

 OK Max. In the last version you can find the "likely" final version.
 It's extremely simple, easy to use, and very very little code. Only one
 override. All WADynamicVariables subclasses handled automatically. All you
 need to do is to register the handler:

 app filter configuration at: #exceptionHandler put:
 WAPharoDebuggererErrorHandler.

 It works for exceptions and both Halt too. The only limit is only the
 "last opened debugger" will be correct and all previous will be wrong since
 they will be using another values for dynamic variables.

 I will see if people want to integrate this directly into Seaside.


 Very nice! And since you provide a separate error handler it’s easy to
 integrate into seaside too by simply adding it to the handler chain.


>>> Exactly. The only issue to fix is the override in WADynamicVariable >>
>>> defaultAction.
>>> And that's not easy. Why? Because at that level, we know nothing about
>>> the current seaside app or anything. We don't know which seaside app those
>>> signal came from. Of course, I can still do the check to the handler to see
>>> if that has that variable stored. But... What if now you have set another
>>> error handler? Or what about OTHER possible registered apps which use a
>>> different error handler.
>>> Thoughts?  I have some HACKS in mind, but they are hacks and none solves
>>> all problems. And only for Pharo.
>>> Any idea to solve this would be nice.
>>>
>>>
>> Assuming you are using GTDebugger (should be very easy to adapt for
>> normal debugger), we can do this:
>>
>> defaultAction
>> " This is an override from SeasidePharoDebugging because before raising a
>> signal we
>> first check if we have the value stored. That way, everywhere
>> we evaluate code in a debugger that end ups doing
>> 'WACurrentRequestContext value' will simply
>> get up to this place. Since in WAPharoDebuggererErrorHandler >> #open:  we
>> stored the dynamic variables, we should have the value "
>> | openedSeasideErrorDebuggers |
>> *openedSeasideErrorDebuggers := ((UIManager default currentWorld
>> submorphs select: [ :each | each model isKindOf: GTGenericStackDebugger ]) *
>> * collect: [ :each | each model ]) *
>> * select: [ :each2 | (each2 session interruptedProcess suspendedContext
>> method selector = #openDebuggerOn:)*
>> * and: (each2 session interruptedProcess suspendedContext sender receiver
>> class = WADynamicVariablesErrorHandler) ].*
>> ^ openedSeasideErrorDebuggers
>> ifEmpty: [ self class defaultValue ]
>> ifNotEmpty: [
>> (WADynamicVariablesErrorHandler storedDynamicVariable: self class)
>> ifNil: [ self class defaultValue ]
>> ]
>>
>> But that..the only thing it solves is that we would not be getting the
>> value of dynamic variables from previous errors if there is none debugger
>> opened from a seaside continuation. If you let a debugger opened debugging
>> a seaside error, then there is no magic we can do I think.
>> Imagine you were in a debugger and you evaluated: "WAComponent new
>> session". The signal raised from there knows NOTHING about the debugger
>> where that was evaluated... so at #defaultAction level you know nothing
>> about what triggered that.
>>
>> The only thing to solve this would be to hook into the do-it, print it,
>> inspect etc...too complicated.
>>
>>
>> Thoughts?
>>
>>
>> I think you’re solution is already pretty good. I wouldn’t really care if
>> multiple debuggers are a problem. Evaluating a piece of code in context of
>> the dynamic variables is already a lot of help. Although, if you don’t know
>> that you’re seeing a different session / request, that’s bad...
>>
>> I do have one idea but it might be a bit more complicated and is not
>> Seaside specific: if we could attach the context of the evaluation to the
>> suspended context, the handler search should automatically yield the
>> correct handlers for the dynamic variables (although I don’t know exactly
>> how the VM resolves the handlers). Alternatively, instead of attaching the
>> whole stack, it would suffice to copy the handler contexts and attach them
>> to the evaluation context. Both approaches would also solve the problem of
>> multiple debuggers.
>>
>
> Yes, I have thought about doing something similar. In GemStone for
> example, there is another possibility since it allows global static handler
> for exceptions. So for example you can say install a block to be executed
> when nobody handled exception XXX.

Re: [Pharo-dev] CompilationContext class>>initialize

[Marcus Denker]

they don’t… I think that is a leftover from back when we had some rule 
or automatic suggestion to add the “super initialize”, which is wrong on the
class side.

> On 11 Dec 2015, at 16:55, Stephan Eggermont  wrote:
> 
> Why do CompilationContext and CCompilationContext need super initialize in 
> class side initialize?
> 
> Stephan
> 
> 

[Pharo-dev] CompilationContext class>>initialize

[Stephan Eggermont]

Why do CompilationContext and CCompilationContext need super initialize 
in class side initialize?


Stephan

Re: [Pharo-dev] Unicode Support

[Richard Sargent]

EuanM wrote
> ...
> all ISO-8859-1 maps 1:1 to Unicode UTF-8
> ...

I am late coming in to this conversation. If it hasn't already been said,
please do not conflate Unicode and UTF-8. I think that would be a recipe for
a high P.I.T.A. factor.

Unicode defines the meaning of the code points.
UTF-8 (and -16) define an interchange mechanism.

In other words, when you write the code points to an external medium
(socket, file, whatever), encode them via UTF-whatever. Read UTF-whatever
from an external medium and re-instantiate the code points.
(Personally, I see no use for UTF-16 as an interchange mechanism. Others may
have justification for it. I don't.)

Having characters be a consistent size in their object representation makes
everything easier. #at:, #indexOf:, #includes: ... no one wants to be
scanning through bytes representing variable sized characters.

Model Unicode strings using classes such as e.g. Unicode7, Unicode16, and
Unicode32, with automatic coercion to the larger character width.




--
View this message in context: 
http://forum.world.st/Unicode-Support-tp4865139p4866610.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Some GT tool for this?

[Eliot Miranda]

Hi Mariano,

for this in Squeak I added a simple menu pick to the Monticello Browser's 
package list menu called "search history" which opens up a workspace containing 
the entire history as a flat string.  I then just search using ctrl-f.  You can 
find it in a current squeak trunk image.

_,,,^..^,,,_ (phone)

> On Dec 10, 2015, at 9:12 AM, Mariano Martinez Peck  
> wrote:
> 
> How many times have you tried to search a string as a comment of a commit in 
> all the history? Myself: many many times. I know we need much better tools 
> for that, store the history in a another way, provide a nicer API, etc etc. 
> And I know there were topics about that. 
> 
> However, I would deeply appreciate a very short term solution for ease that. 
> The model side is as simple as this:
> 
> | packageName ancestry anscestors substring | 
> packageName := 'MyPackageXX'.
> substring := 'whatever I want to search'.
> ancestry := (MCWorkingCopy allManagers detect: [:each | each packageName = 
> packageName] ) ancestry.  
> anscestors := ancestry withBreadthFirstAncestors select: [:each | each 
> isKindOf: MCVersionInfo].
> anscestors select: [ :each | each message includesSubstring: substring ]
> 
> Do you think it's worth a simple UI tool? Custom inspector of MCAncestry?
> 
> Cheers,
> 
> 
> -- 
> Mariano
> http://marianopeck.wordpress.com

Re: [Pharo-dev] Hook "WACurrentRequestContext" into debugger?

[Max Leske]

> On 11 Dec 2015, at 16:39, Mariano Martinez Peck  wrote:
> 
> 
> 
> On Fri, Dec 11, 2015 at 12:25 PM, Max Leske  > wrote:
> 
>> On 10 Dec 2015, at 21:21, Mariano Martinez Peck > > wrote:
>> 
>> 
>> 
>> On Thu, Dec 10, 2015 at 4:12 PM, Mariano Martinez Peck 
>> mailto:marianop...@gmail.com>> wrote:
>> 
>> 
>> On Thu, Dec 10, 2015 at 7:27 AM, Max Leske > > wrote:
>> 
>>> On 07 Dec 2015, at 17:17, Mariano Martinez Peck >> > wrote:
>>> 
>>> OK Max. In the last version you can find the "likely" final version. It's 
>>> extremely simple, easy to use, and very very little code. Only one 
>>> override. All WADynamicVariables subclasses handled automatically. All you 
>>> need to do is to register the handler:
>>> 
>>> app filter configuration at: #exceptionHandler put: 
>>> WAPharoDebuggererErrorHandler.
>>> 
>>> It works for exceptions and both Halt too. The only limit is only the "last 
>>> opened debugger" will be correct and all previous will be wrong since they 
>>> will be using another values for dynamic variables. 
>>> 
>>> I will see if people want to integrate this directly into Seaside.
>> 
>> Very nice! And since you provide a separate error handler it’s easy to 
>> integrate into seaside too by simply adding it to the handler chain.
>> 
>> 
>> Exactly. The only issue to fix is the override in WADynamicVariable >> 
>> defaultAction. 
>> And that's not easy. Why? Because at that level, we know nothing about the 
>> current seaside app or anything. We don't know which seaside app those 
>> signal came from. Of course, I can still do the check to the handler to see 
>> if that has that variable stored. But... What if now you have set another 
>> error handler? Or what about OTHER possible registered apps which use a 
>> different error handler.  
>> Thoughts?  I have some HACKS in mind, but they are hacks and none solves all 
>> problems. And only for Pharo. 
>> Any idea to solve this would be nice. 
>> 
>> 
>> Assuming you are using GTDebugger (should be very easy to adapt for normal 
>> debugger), we can do this:
>> 
>> defaultAction
>>  " This is an override from SeasidePharoDebugging because before raising 
>> a signal we 
>>  first check if we have the value stored. That way, everywhere 
>>  we evaluate code in a debugger that end ups doing 
>> 'WACurrentRequestContext value' will simply  
>>  get up to this place. Since in WAPharoDebuggererErrorHandler >> #open:  
>> we
>>  stored the dynamic variables, we should have the value "
>>  | openedSeasideErrorDebuggers |
>>  openedSeasideErrorDebuggers := ((UIManager default currentWorld 
>> submorphs select: [ :each | each model isKindOf: GTGenericStackDebugger ]) 
>>  collect: [ :each | each model ])
>>  select: [ :each2 | (each2 session interruptedProcess 
>> suspendedContext method selector = #openDebuggerOn:)
>>  
>> and: (each2 session interruptedProcess suspendedContext sender receiver 
>> class = WADynamicVariablesErrorHandler) ].
>>  ^ openedSeasideErrorDebuggers 
>>  ifEmpty: [ self class defaultValue ]
>>  ifNotEmpty: [  
>>  (WADynamicVariablesErrorHandler storedDynamicVariable: 
>> self class)
>>  ifNil: [ self class defaultValue ]
>>  ]
>>  
>> 
>> But that..the only thing it solves is that we would not be getting the value 
>> of dynamic variables from previous errors if there is none debugger opened 
>> from a seaside continuation. If you let a debugger opened debugging a 
>> seaside error, then there is no magic we can do I think. 
>> Imagine you were in a debugger and you evaluated: "WAComponent new session". 
>> The signal raised from there knows NOTHING about the debugger where that was 
>> evaluated... so at #defaultAction level you know nothing about what 
>> triggered that.
>>  
>> The only thing to solve this would be to hook into the do-it, print it, 
>> inspect etc...too complicated. 
>> 
>> 
>> Thoughts?
> 
> I think you’re solution is already pretty good. I wouldn’t really care if 
> multiple debuggers are a problem. Evaluating a piece of code in context of 
> the dynamic variables is already a lot of help. Although, if you don’t know 
> that you’re seeing a different session / request, that’s bad...
> 
> I do have one idea but it might be a bit more complicated and is not Seaside 
> specific: if we could attach the context of the evaluation to the suspended 
> context, the handler search should automatically yield the correct handlers 
> for the dynamic variables (although I don’t know exactly how the VM resolves 
> the handlers). Alternatively, instead of attaching the whole stack, it would 
> suffice to copy the handler contexts and attach them to the evaluation 
> context. Both appr

Re: [Pharo-dev] Hook "WACurrentRequestContext" into debugger?

[Mariano Martinez Peck]

On Fri, Dec 11, 2015 at 12:25 PM, Max Leske  wrote:

>
> On 10 Dec 2015, at 21:21, Mariano Martinez Peck 
> wrote:
>
>
>
> On Thu, Dec 10, 2015 at 4:12 PM, Mariano Martinez Peck <
> marianop...@gmail.com> wrote:
>
>>
>>
>> On Thu, Dec 10, 2015 at 7:27 AM, Max Leske  wrote:
>>
>>>
>>> On 07 Dec 2015, at 17:17, Mariano Martinez Peck 
>>> wrote:
>>>
>>> OK Max. In the last version you can find the "likely" final version.
>>> It's extremely simple, easy to use, and very very little code. Only one
>>> override. All WADynamicVariables subclasses handled automatically. All you
>>> need to do is to register the handler:
>>>
>>> app filter configuration at: #exceptionHandler put:
>>> WAPharoDebuggererErrorHandler.
>>>
>>> It works for exceptions and both Halt too. The only limit is only the
>>> "last opened debugger" will be correct and all previous will be wrong since
>>> they will be using another values for dynamic variables.
>>>
>>> I will see if people want to integrate this directly into Seaside.
>>>
>>>
>>> Very nice! And since you provide a separate error handler it’s easy to
>>> integrate into seaside too by simply adding it to the handler chain.
>>>
>>>
>> Exactly. The only issue to fix is the override in WADynamicVariable >>
>> defaultAction.
>> And that's not easy. Why? Because at that level, we know nothing about
>> the current seaside app or anything. We don't know which seaside app those
>> signal came from. Of course, I can still do the check to the handler to see
>> if that has that variable stored. But... What if now you have set another
>> error handler? Or what about OTHER possible registered apps which use a
>> different error handler.
>> Thoughts?  I have some HACKS in mind, but they are hacks and none solves
>> all problems. And only for Pharo.
>> Any idea to solve this would be nice.
>>
>>
> Assuming you are using GTDebugger (should be very easy to adapt for normal
> debugger), we can do this:
>
> defaultAction
> " This is an override from SeasidePharoDebugging because before raising a
> signal we
> first check if we have the value stored. That way, everywhere
> we evaluate code in a debugger that end ups doing 'WACurrentRequestContext
> value' will simply
> get up to this place. Since in WAPharoDebuggererErrorHandler >> #open:  we
> stored the dynamic variables, we should have the value "
> | openedSeasideErrorDebuggers |
> *openedSeasideErrorDebuggers := ((UIManager default currentWorld submorphs
> select: [ :each | each model isKindOf: GTGenericStackDebugger ]) *
> * collect: [ :each | each model ]) *
> * select: [ :each2 | (each2 session interruptedProcess suspendedContext
> method selector = #openDebuggerOn:)*
> * and: (each2 session interruptedProcess suspendedContext sender receiver
> class = WADynamicVariablesErrorHandler) ].*
> ^ openedSeasideErrorDebuggers
> ifEmpty: [ self class defaultValue ]
> ifNotEmpty: [
> (WADynamicVariablesErrorHandler storedDynamicVariable: self class)
> ifNil: [ self class defaultValue ]
> ]
>
> But that..the only thing it solves is that we would not be getting the
> value of dynamic variables from previous errors if there is none debugger
> opened from a seaside continuation. If you let a debugger opened debugging
> a seaside error, then there is no magic we can do I think.
> Imagine you were in a debugger and you evaluated: "WAComponent new
> session". The signal raised from there knows NOTHING about the debugger
> where that was evaluated... so at #defaultAction level you know nothing
> about what triggered that.
>
> The only thing to solve this would be to hook into the do-it, print it,
> inspect etc...too complicated.
>
>
> Thoughts?
>
>
> I think you’re solution is already pretty good. I wouldn’t really care if
> multiple debuggers are a problem. Evaluating a piece of code in context of
> the dynamic variables is already a lot of help. Although, if you don’t know
> that you’re seeing a different session / request, that’s bad...
>
> I do have one idea but it might be a bit more complicated and is not
> Seaside specific: if we could attach the context of the evaluation to the
> suspended context, the handler search should automatically yield the
> correct handlers for the dynamic variables (although I don’t know exactly
> how the VM resolves the handlers). Alternatively, instead of attaching the
> whole stack, it would suffice to copy the handler contexts and attach them
> to the evaluation context. Both approaches would also solve the problem of
> multiple debuggers.
>

Yes, I have thought about doing something similar. In GemStone for example,
there is another possibility since it allows global static handler for
exceptions. So for example you can say install a block to be executed when
nobody handled exception XXX. And that closure execution is BEFORE the
#defaultAction. So for example in this case I would be able to do that
without the override in WADynamicVariable >> defaultAction.
m I am not 100% sure about what I said about GemStone hahahah

Re: [Pharo-dev] Why Zinc servers implemented with options dictionary instead of normal instance variables?

[Denis Kudriashov]

2015-12-11 15:51 GMT+01:00 Sven Van Caekenberghe :

> Because there are many options, 10, 20, and at that time slots were not
> yet available.
>

Is not it is same case as class with 20 variables which always smell bad?

Re: [Pharo-dev] Hook "WACurrentRequestContext" into debugger?

[Max Leske]

> On 10 Dec 2015, at 21:21, Mariano Martinez Peck  wrote:
> 
> 
> 
> On Thu, Dec 10, 2015 at 4:12 PM, Mariano Martinez Peck  > wrote:
> 
> 
> On Thu, Dec 10, 2015 at 7:27 AM, Max Leske  > wrote:
> 
>> On 07 Dec 2015, at 17:17, Mariano Martinez Peck > > wrote:
>> 
>> OK Max. In the last version you can find the "likely" final version. It's 
>> extremely simple, easy to use, and very very little code. Only one override. 
>> All WADynamicVariables subclasses handled automatically. All you need to do 
>> is to register the handler:
>> 
>>  app filter configuration at: #exceptionHandler put: 
>> WAPharoDebuggererErrorHandler.
>> 
>> It works for exceptions and both Halt too. The only limit is only the "last 
>> opened debugger" will be correct and all previous will be wrong since they 
>> will be using another values for dynamic variables. 
>> 
>> I will see if people want to integrate this directly into Seaside.
> 
> Very nice! And since you provide a separate error handler it’s easy to 
> integrate into seaside too by simply adding it to the handler chain.
> 
> 
> Exactly. The only issue to fix is the override in WADynamicVariable >> 
> defaultAction. 
> And that's not easy. Why? Because at that level, we know nothing about the 
> current seaside app or anything. We don't know which seaside app those signal 
> came from. Of course, I can still do the check to the handler to see if that 
> has that variable stored. But... What if now you have set another error 
> handler? Or what about OTHER possible registered apps which use a different 
> error handler.  
> Thoughts?  I have some HACKS in mind, but they are hacks and none solves all 
> problems. And only for Pharo. 
> Any idea to solve this would be nice. 
> 
> 
> Assuming you are using GTDebugger (should be very easy to adapt for normal 
> debugger), we can do this:
> 
> defaultAction
>   " This is an override from SeasidePharoDebugging because before raising 
> a signal we 
>   first check if we have the value stored. That way, everywhere 
>   we evaluate code in a debugger that end ups doing 
> 'WACurrentRequestContext value' will simply  
>   get up to this place. Since in WAPharoDebuggererErrorHandler >> #open:  
> we
>   stored the dynamic variables, we should have the value "
>   | openedSeasideErrorDebuggers |
>   openedSeasideErrorDebuggers := ((UIManager default currentWorld 
> submorphs select: [ :each | each model isKindOf: GTGenericStackDebugger ]) 
>   collect: [ :each | each model ])
>   select: [ :each2 | (each2 session interruptedProcess 
> suspendedContext method selector = #openDebuggerOn:)
>   
> and: (each2 session interruptedProcess suspendedContext sender receiver class 
> = WADynamicVariablesErrorHandler) ].
>   ^ openedSeasideErrorDebuggers 
>   ifEmpty: [ self class defaultValue ]
>   ifNotEmpty: [  
>   (WADynamicVariablesErrorHandler storedDynamicVariable: 
> self class)
>   ifNil: [ self class defaultValue ]
>   ]
>   
> 
> But that..the only thing it solves is that we would not be getting the value 
> of dynamic variables from previous errors if there is none debugger opened 
> from a seaside continuation. If you let a debugger opened debugging a seaside 
> error, then there is no magic we can do I think. 
> Imagine you were in a debugger and you evaluated: "WAComponent new session". 
> The signal raised from there knows NOTHING about the debugger where that was 
> evaluated... so at #defaultAction level you know nothing about what triggered 
> that.
>  
> The only thing to solve this would be to hook into the do-it, print it, 
> inspect etc...too complicated. 
> 
> 
> Thoughts?

I think you’re solution is already pretty good. I wouldn’t really care if 
multiple debuggers are a problem. Evaluating a piece of code in context of the 
dynamic variables is already a lot of help. Although, if you don’t know that 
you’re seeing a different session / request, that’s bad...

I do have one idea but it might be a bit more complicated and is not Seaside 
specific: if we could attach the context of the evaluation to the suspended 
context, the handler search should automatically yield the correct handlers for 
the dynamic variables (although I don’t know exactly how the VM resolves the 
handlers). Alternatively, instead of attaching the whole stack, it would 
suffice to copy the handler contexts and attach them to the evaluation context. 
Both approaches would also solve the problem of multiple debuggers.

For this to work the debugger would need highjack the evaluation of code e.g. 
by using a custom code editor.
The cool thing about this would be that every evaluation would run in the same 
exception handling contexts as the

[Pharo-dev] a little poll on the importance of architecture

[Tudor Girba]

Hi,

I created another little poll about the importance of architecture.

If you have a Twitter account, feel free to participate:
https://twitter.com/girba/status/675330047608299521

Cheers,
Doru


--
www.tudorgirba.com

"Things happen when they happen,
not when you talk about them happening."

Re: [Pharo-dev] Why Zinc servers implemented with options dictionary instead of normal instance variables?

[Sven Van Caekenberghe]

Because there are many options, 10, 20, and at that time slots were not yet 
available.

It also makes it easier/clearer to treat them consistently.

> On 11 Dec 2015, at 15:46, Denis Kudriashov  wrote:
> 
> Hello.
> 
> Just looked on ZnServer code. And I was wondering when see that everything is 
> stored inside "options" variable (which is dictionary). For example port 
> number is option which is really strange.
> 
> What the reason for that?

[Pharo-dev] Why Zinc servers implemented with options dictionary instead of normal instance variables?

[Denis Kudriashov]

Hello.

Just looked on ZnServer code. And I was wondering when see that everything
is stored inside "options" variable (which is dictionary). For example port
number is option which is really strange.

What the reason for that?