Re: [Pharo-dev] Executive Programming

[Ben Coman]

I guess one thing important to C-level executives are relationships between
people
so the old reliable Contact Book might work.  This could be done in several
levels:
* basic - addresses & birthdays colleagues & family
* intermediate - interface with external services to automatically send
email
* advanced - automatically buy a present from colleague's Amazon wish list

Bonus points if the interface works well from a smart phone.


Along the same of people relationships, maybe they would be interested in a
way to mine Facebook / LinkedIn data,
but their may be sensitive non-technical issues to be careful of here

or trawl news feeds doing sentiment analysis of their company.

cheers -ben


On 7 April 2018 at 23:20, Stephane Ducasse  wrote:

> Ben
>
> what would be interesting to build is a case: what a Boss would like to
> code?
> Because once we have this case we could model it and have a DSL
> (pharo) to script it.
>
> Stef
>
> On Sat, Apr 7, 2018 at 8:36 AM, Ben Coman  wrote:
> > This article about the "Mining Industry's Impending Digital
> Metamorphosis"
> > https://medium.com/@CORE_Innovation/minings-impending-
> metamorphosis-155d66869149
> >
> > is a little off topic, except where it says "All levels, including
> > management and executives will need to have some level coding experience
> and
> > understanding."
> >
> > made me think this must be pervasive across many industries and that an
> > interesting strategy
> > for Pharo would be teaching a course called... "Executive Programming".
> > Pharo could be ideally suited to filling this niche...
> > * Executives don't need to learn the *most* efficient language (i.e. C),
> > * and don't need to learn a system suited to large groups of developers
> > (i.e. Java)
> > * and don't have the time to wait for things to compile (i.e. big tick
> > immediate feedback)
> > They are never going to "do the work" but just need to gain a general
> > understanding of "programming" to better strategise at a higher level and
> > interact with developers.
> > What better language is there for this than Pharo?
> >
> > But guess what happens when the boss is familiar with and likes one
> > particular language... ?
> >
> > /cue maniacal laugh
> >
> > cheers -ben
> >
> > P.S. I'd be interested in collaborating on something that is not an end
> user
> > book, but more of an Instructors manual for such a course.
>
>

Re: [Pharo-dev] Executive Programming

[Ben Coman]

On 11 April 2018 at 02:55, askoh  wrote:

> Ben:
>
> I have been thinking along the same lines.
> Smalltalk is my PersonalOS.
>

Nice idea, but its a long step beyond what I had in mind.
I don't expect an executive to be using Pharo daily.   Their daily time is
better spent elsewhere.
I expect the majority would want to round out their background knowledge
to fill that gap "you don't know what you don't know."

What they want is "maximum impact in minimum time"  [whoops "bingo sir" (
http://dilbert.com/strip/1994-02-22)]
Actually thats makes me think "Pharo - the fastest way to learn
programming"
would make a good tagline for this.

cheers -ben




>
> Instead of *.bat or *.sh files, I would use Smalltalk to call OS commands
> directly in methods to do what I want in the OS while using Smalltalk to do
> the logic. PersonalOS should be able to run on multiple OS's using the same
> methods to do the same things. So, an easy interface to OS commands and
> possibly OS APIs would encourage people to use Smalltalk for controlling
> everything else. Smalltalk would be the center of control and automation
> from individuals to corporations and beyond.
>
> Hopefully, we can get critical mass with this.
>

Re: [Pharo-dev] Why String do not implement #displayString?

[Esteban A. Maringolo]

In Object yes (to default to the existing #printOn: implementation), but
there are several other implementors of #displayOn: that work completely
different (e.g. Collection, UndefinedObject, etc).

Nonetheless, I think the #printOn:/#displayOn: is a good practice, in my
Pharo classes I "polyfill" what's missing to support it.

Regards!


On 10/04/2018 19:42, Benoit St-Jean wrote:
> As far as I can remember, yes.  Dolphin has always been like that.
> 
> ***BUT*** you will also notice that Dolphin has always used #printOn:
> inside #displayOn: ! (Latest image is also like that)
> 
> 
> On Tuesday, April 10, 2018, 6:33:05 p.m. EDT, Esteban A. Maringolo
>  wrote:
> 
> 
> Current VisualWorks (8.x) has #Object>>displayString but it is not
> implemented in terms of #displayOn:
> 
> Dolphin Smalltalk is the one that has #displayString implemented in
> terms of #displayOn: and uses #displayString in all end user
> presentations of the object, so for aPerson, the inspector would show 'a
> Person('John Doe')' and on a end user ListView the same instance would
> show 'John Doe'.
> 
> It is like that since Dolphin 5 at least (~2003?).

Re: [Pharo-dev] Why String do not implement #displayString?

[Benoit St-Jean via Pharo-dev]

--- Begin Message ---
As far as I can remember, yes.  Dolphin has always been like that.
***BUT*** you will also notice that Dolphin has always used #printOn: inside 
#displayOn: ! (Latest image is also like that)


- 
Benoît St-Jean 
Yahoo! Messenger: bstjean 
Twitter: @BenLeChialeux 
Pinterest: benoitstjean 
Instagram: Chef_Benito
IRC: lamneth 
Blogue: endormitoire.wordpress.com 
"A standpoint is an intellectual horizon of radius zero".  (A. Einstein) 

On Tuesday, April 10, 2018, 6:33:05 p.m. EDT, Esteban A. Maringolo 
 wrote:  
 
  
Current VisualWorks (8.x) has #Object>>displayString but it is not implemented 
in terms of #displayOn:
 
Dolphin Smalltalk is the one that has #displayString implemented in terms of 
#displayOn: and uses #displayString in all end user presentations of the 
object, so for aPerson, the inspector would show 'a Person('John Doe')' and on 
a end user ListView the same instance would show 'John Doe'.
 
 
It is like that since Dolphin 5 at least (~2003?).
 
 
Regards,
 
 
 On 10/04/2018 19:04, Benoit St-Jean wrote:
  
  In the "old" days, programmers made sure to respect the following conventions 
: you implement #storeOn:, #displayString: and #printOn: .  Eventually, an 
object will be sent #storeString and #printString and will use your 
#whateverOn: implementation.   
  It looks like that good habit that I've learned at university looong ago 
got lost somewhere.  It looks like no one uses #displayString anymore and rely 
solely on #printString instead!  I had a teacher once telling me #displayString 
had a crappy implementation : it just sent #printString and that to be "code 
clean", one should implement  #displayOn: and modify #displayString 
accordingly. 
  But if I recall, VW at the time introduced #displayOn: for widgets and other 
things, hence why #displayString never sent #displayOn:. 
  To make a long story short of what should have been and what it's always 
been, here's an excellent paper on the subject! 
  http://esug.org/data/HistoricalDocuments/TheSmalltalkReport/ST07/04wo.pdf 
  
  - 
 Benoît St-Jean 
 Yahoo! Messenger: bstjean 
 Twitter: @BenLeChialeux 
 Pinterest: benoitstjean 
 Instagram: Chef_Benito
 IRC: lamneth 
 Blogue: endormitoire.wordpress.com 
 "A standpoint is an intellectual horizon of radius zero".  (A. Einstein)  
  
 On Tuesday, April 10, 2018, 11:28:57 a.m. EDT, Esteban A. Maringolo 
 wrote:  
  
   Isn't #displayString implemented in terms of #displayOn: the same way
 #printString is implemented in terms of "printOn:"?
 
 And in the case of String #displayString should return the receiver (it
 is, self), so the following should be true.
 
 | s |
 s := 'Hello, ''Funny'' World'.
 s displayString = s. "true"
 s printString = s. "false"
 
 Regards,
 
 
 On 10/04/2018 12:21, Denis Kudriashov wrote:
 > Hi.
 > 
 > According to the comment of #displayString it should be used as default
 > textual representation of objects in the UI:
 > 
 >    "While printString is about to give a detailled information about an
 >    object, displayString is a message that should return a short
 >    string-based representation to be used by list and related UI
 >    frameworks. By default, simply return printString."
 >    "asString should not be implemented in Object, and kept for
 >    conversion between strings, symbols, text and characters."
 > 
 > But String itself does not respect this message:
 > 
 >    'some string' displayString " ==> '''someString''' "
 > 
 > 
 > Is it bug? Or is there any reason for this?
 > 
 > Best regards,
 > Denis 
 
 -- 
 Esteban A. Maringolo 
 
   
 
 -- 
Esteban A. Maringolo   --- End Message ---

Re: [Pharo-dev] Images, VMs and 32 vs 64bit

[Benoit St-Jean via Pharo-dev]

--- Begin Message ---
Thanks!
I don't really care about the image format, my question was more oriented 
towards the code itself.  As I don't have a Mac, I was curious as to whether 
there would be code differences between platforms, VMs and 32 vs 64bit 
distributions, code-wise!


- 
Benoît St-Jean 
Yahoo! Messenger: bstjean 
Twitter: @BenLeChialeux 
Pinterest: benoitstjean 
Instagram: Chef_Benito
IRC: lamneth 
Blogue: endormitoire.wordpress.com 
"A standpoint is an intellectual horizon of radius zero".  (A. Einstein) 

On Tuesday, April 10, 2018, 6:29:33 p.m. EDT, Peter Uhnák 
 wrote:  
 
 > images for different platforms (Mac, Linux, Windows)
yesIt is the responsibility of the VM to contain the differences. Note that 
there's some "platform-specific" code, but the image contains the code for all 
platforms at once.Generally speaking you can code on one platform, copy the 
image files to another and continue your work (although doing this can cause 
trouble, as e.g. some file paths may now point to non-existing locations).You 
can download the images independently of the platform too (e.g. Pharo 6 images: 
http://files.pharo.org/image/60/ )
> VMs (32bit, 64bit)

yes?the files are different, but I don't know if there's code difference, or if 
the images are just built with different memory layouts
Peter
On Wed, Apr 11, 2018 at 12:13 AM, Benoit St-Jean via Pharo-dev 
 wrote:



-- Forwarded message --
From: Benoit St-Jean 
To: Pharo Development List 
Cc: 
Bcc: 
Date: Tue, 10 Apr 2018 22:13:18 + (UTC)
Subject: Images, VMs and 32 vs 64bit
I was wondering if images for different platforms (Mac, Linux, Windows) and VMs 
(32bit, 64bit) are, code-wise, the same?  By "the same", I mean do they all 
have the exact same code base or some classes/methods are in some and not in 
others or different?

- 
Benoît St-Jean 
Yahoo! Messenger: bstjean 
Twitter: @BenLeChialeux 
Pinterest: benoitstjean 
Instagram: Chef_Benito
IRC: lamneth 
Blogue: endormitoire.wordpress.com 
"A standpoint is an intellectual horizon of radius zero".  (A. Einstein)


  --- End Message ---

Re: [Pharo-dev] Why String do not implement #displayString?

[Esteban A. Maringolo]

Current VisualWorks (8.x) has #Object>>displayString but it is not
implemented in terms of #displayOn:

Dolphin Smalltalk is the one that has #displayString implemented in
terms of #displayOn: and uses #displayString in all end user
presentations of the object, so for aPerson, the inspector would show 'a
Person('John Doe')' and on a end user ListView the same instance would
show 'John Doe'.

It is like that since Dolphin 5 at least (~2003?).

Regards,


On 10/04/2018 19:04, Benoit St-Jean wrote:
> In the "old" days, programmers made sure to respect the following
> conventions : you implement #storeOn:, #displayString: and #printOn:
> .  Eventually, an object will be sent #storeString and #printString
> and will use your #whateverOn: implementation. 
>
> It looks like that good habit that I've learned at university
> looong ago got lost somewhere.  It looks like no one uses
> #displayString anymore and rely solely on #printString instead!  I had
> a teacher once telling me #displayString had a crappy implementation :
> it just sent #printString and that to be "code clean", one should
> implement #displayOn: and modify #displayString accordingly.
>
> But if I recall, VW at the time introduced #displayOn: for widgets and
> other things, hence why #displayString never sent #displayOn:.
>
> To make a long story short of what should have been and what it's
> always been, here's an excellent paper on the subject!
>
> http://esug.org/data/HistoricalDocuments/TheSmalltalkReport/ST07/04wo.pdf
>
>
> -
> Benoît St-Jean
> Yahoo! Messenger: bstjean
> Twitter: @BenLeChialeux
> Pinterest: benoitstjean
> Instagram: Chef_Benito
> IRC: lamneth
> Blogue: endormitoire.wordpress.com
> "A standpoint is an intellectual horizon of radius zero".  (A. Einstein)
>
>
> On Tuesday, April 10, 2018, 11:28:57 a.m. EDT, Esteban A. Maringolo
>  wrote:
>
>
> Isn't #displayString implemented in terms of #displayOn: the same way
> #printString is implemented in terms of "printOn:"?
>
> And in the case of String #displayString should return the receiver (it
> is, self), so the following should be true.
>
> | s |
> s := 'Hello, ''Funny'' World'.
> s displayString = s. "true"
> s printString = s. "false"
>
> Regards,
>
>
> On 10/04/2018 12:21, Denis Kudriashov wrote:
> > Hi.
> >
> > According to the comment of #displayString it should be used as default
> > textual representation of objects in the UI:
> >
> >    "While printString is about to give a detailled information about an
> >    object, displayString is a message that should return a short
> >    string-based representation to be used by list and related UI
> >    frameworks. By default, simply return printString."
> >    "asString should not be implemented in Object, and kept for
> >    conversion between strings, symbols, text and characters."
> >
> > But String itself does not respect this message:
> >
> >    'some string' displayString " ==> '''someString''' "
> >
> >
> > Is it bug? Or is there any reason for this?
> >
> > Best regards,
> > Denis
>
>
> -- 
> Esteban A. Maringolo
>
>

-- 
Esteban A. Maringolo

Re: [Pharo-dev] Images, VMs and 32 vs 64bit

[Peter Uhnák]

> images for different platforms (Mac, Linux, Windows)

yes
It is the responsibility of the VM to contain the differences. Note that
there's some "platform-specific" code, but the image contains the code for
all platforms at once.
Generally speaking you can code on one platform, copy the image files to
another and continue your work (although doing this can cause trouble, as
e.g. some file paths may now point to non-existing locations).
You can download the images independently of the platform too (e.g. Pharo 6
images: http://files.pharo.org/image/60/ )

> VMs (32bit, 64bit)

yes?
the files are different, but I don't know if there's code difference, or if
the images are just built with different memory layouts

Peter

On Wed, Apr 11, 2018 at 12:13 AM, Benoit St-Jean via Pharo-dev <
pharo-dev@lists.pharo.org> wrote:

>
>
> -- Forwarded message --
> From: Benoit St-Jean 
> To: Pharo Development List 
> Cc:
> Bcc:
> Date: Tue, 10 Apr 2018 22:13:18 + (UTC)
> Subject: Images, VMs and 32 vs 64bit
> I was wondering if images for different platforms (Mac, Linux, Windows)
> and VMs (32bit, 64bit) are, code-wise, the same?  By "the same", I mean do
> they all have the exact same code base or some classes/methods are in some
> and not in others or different?
>
> -
> Benoît St-Jean
> Yahoo! Messenger: bstjean
> Twitter: @BenLeChialeux
> Pinterest: benoitstjean
> Instagram: Chef_Benito
> IRC: lamneth
> Blogue: endormitoire.wordpress.com
> "A standpoint is an intellectual horizon of radius zero".  (A. Einstein)
>
>

[Pharo-dev] Images, VMs and 32 vs 64bit

[Benoit St-Jean via Pharo-dev]

--- Begin Message ---
I was wondering if images for different platforms (Mac, Linux, Windows) and VMs 
(32bit, 64bit) are, code-wise, the same?  By "the same", I mean do they all 
have the exact same code base or some classes/methods are in some and not in 
others or different?

- 
Benoît St-Jean 
Yahoo! Messenger: bstjean 
Twitter: @BenLeChialeux 
Pinterest: benoitstjean 
Instagram: Chef_Benito
IRC: lamneth 
Blogue: endormitoire.wordpress.com 
"A standpoint is an intellectual horizon of radius zero".  (A. Einstein)--- End Message ---

Re: [Pharo-dev] Why String do not implement #displayString?

[Benoit St-Jean via Pharo-dev]

--- Begin Message ---
In the "old" days, programmers made sure to respect the following conventions : 
you implement #storeOn:, #displayString: and #printOn: .  Eventually, an object 
will be sent #storeString and #printString and will use your #whateverOn: 
implementation.  
It looks like that good habit that I've learned at university looong ago 
got lost somewhere.  It looks like no one uses #displayString anymore and rely 
solely on #printString instead!  I had a teacher once telling me #displayString 
had a crappy implementation : it just sent #printString and that to be "code 
clean", one should implement #displayOn: and modify #displayString accordingly.
But if I recall, VW at the time introduced #displayOn: for widgets and other 
things, hence why #displayString never sent #displayOn:.
To make a long story short of what should have been and what it's always been, 
here's an excellent paper on the subject!
http://esug.org/data/HistoricalDocuments/TheSmalltalkReport/ST07/04wo.pdf

- 
Benoît St-Jean 
Yahoo! Messenger: bstjean 
Twitter: @BenLeChialeux 
Pinterest: benoitstjean 
Instagram: Chef_Benito
IRC: lamneth 
Blogue: endormitoire.wordpress.com 
"A standpoint is an intellectual horizon of radius zero".  (A. Einstein) 

On Tuesday, April 10, 2018, 11:28:57 a.m. EDT, Esteban A. Maringolo 
 wrote:  
 
 Isn't #displayString implemented in terms of #displayOn: the same way
#printString is implemented in terms of "printOn:"?

And in the case of String #displayString should return the receiver (it
is, self), so the following should be true.

| s |
s := 'Hello, ''Funny'' World'.
s displayString = s. "true"
s printString = s. "false"

Regards,


On 10/04/2018 12:21, Denis Kudriashov wrote:
> Hi.
> 
> According to the comment of #displayString it should be used as default
> textual representation of objects in the UI:
> 
>    "While printString is about to give a detailled information about an
>    object, displayString is a message that should return a short
>    string-based representation to be used by list and related UI
>    frameworks. By default, simply return printString."
>    "asString should not be implemented in Object, and kept for
>    conversion between strings, symbols, text and characters."
> 
> But String itself does not respect this message:
> 
>    'some string' displayString " ==> '''someString''' "
> 
> 
> Is it bug? Or is there any reason for this?
> 
> Best regards,
> Denis

-- 
Esteban A. Maringolo

  --- End Message ---

Re: [Pharo-dev] help wanted: normalising LF on tonel for Pharo project

[Peter Uhnák]

>  or a .iceberg file?

Why not use `.properties`?

{
#format : #tonel,
#eol: #lf
}

On Tue, Apr 10, 2018 at 11:55 PM, Esteban Lorenzano 
wrote:

> or a .iceberg file?
>
> Esteban
>
> ps: yep, we need it… we will have it, why not start now?
>
> On 10 Apr 2018, at 23:52, Guillermo Polito 
> wrote:
>
> It could be a checkbox in the "create repository dialog".
>
> "Use lf as default line ending"
>
> (and set it to true by default (?))
>
> On Tue, Apr 10, 2018 at 11:50 PM, Peter Uhnák  wrote:
>
>> An argument can be made that Pharo would _always_ produce LF.
>> I don't think I've ever needed _code_ to be CRLF in a ~decade of using
>> git on Windows. It was always just an annoyance.
>>
>> Peter
>>
>> On Tue, Apr 10, 2018 at 11:44 PM, Esteban Lorenzano 
>> wrote:
>>
>>> hi,
>>>
>>> > On 10 Apr 2018, at 23:17, Esteban A. Maringolo 
>>> wrote:
>>> >
>>> > Not stricly related, or maybe yes, but years ago in InfOil we started
>>> > using Dolphin Smalltalk PAX format[1] for packages with Git, and we
>>> used
>>> > that setting to store code in the repo, we didn't have any issues
>>> >
>>> > The .gitattributes contained this:
>>> > *.img binary
>>> > *.chg binary
>>> > *.sml binary
>>> > OurImage.img merge=ours
>>> > OurImage.chg merge=ours
>>> > *.pax eol=lf
>>> > *.cls eol=lf
>>> >
>>> > .pax was the "package definition" and "method extensions" (methods not
>>> > belonging to the package) file.
>>> > .cls was the 1 file per class+class-side used by this scheme
>>> >
>>> > Even we did everything in Windows for some reason I don't remember (+5
>>> > yrs ago) LF was better for Gitlab. What I also don't remember is if
>>> > during the checkout in the Gitlab CI some conversion was used or not. I
>>> > don't remember a lot of things, but I can ask them if you want.
>>> >
>>> > But I can confirm that this "trick" does work.
>>> >
>>> > Git for Windows even asks you if you want to automatically convert CRLF
>>> > to LF during checkin and back to CRLF on checkout.
>>>
>>> exactly what I want, because pharo/iceberg/tonel uses the system line
>>> ending to write the files :)
>>> thanks!
>>>
>>> Esteban
>>>
>>> ps: otherwise I will need to add some support in-image and I don’t think
>>> is the best approach.
>>> pps: now it remains to see if libgit2 honours the .gitattributes config
>>>
>>> >
>>> > Regards,
>>> >
>>> >
>>> > On 10/04/2018 18:05, Esteban Lorenzano wrote:
>>> >> Hi,
>>> >>
>>> >> I’ve been wondering how to better fix the problem of having windows
>>> and
>>> >> linux/macOS people contributing and the fact that files are written in
>>> >> their native system format (crlf windows, lf for the rest of the
>>> world).
>>> >>
>>> >> I digged a bit and I found a couple a link that helped me (after
>>> trying
>>> >> to understand the
>>> >> doc): https://stackoverflow.com/questions/170961/whats-the-best-cr
>>> lf-carriage-return-line-feed-handling-strategy-with-git
>>> >>
>>> >> and it seems adding a .gitattributes file with this content:
>>> >>
>>> >> # Auto detect text files and perform LF normalization
>>> >> *text=auto
>>> >> *.sttext merge=union eol=lf
>>> >>
>>> >> could fix the problem?
>>> >> can someone confirm this?
>>> >>
>>> >> (I confess this issue confuses me a lot :P)
>>> >>
>>> >> cheers!
>>> >> Esteban
>>> >
>>> > --
>>> > Esteban A. Maringolo
>>> >
>>>
>>>
>>>
>>
>
>
> --
>
> Guille Polito
> Research Engineer
>
>
> Centre de Recherche en Informatique, Signal et Automatique de Lille
> CRIStAL - UMR 9189
> French National Center for Scientific Research - *http://www.cnrs.fr
> *
>
> *Web:* *http://guillep.github.io* 
> *Phone: *+33 06 52 70 66 13
>
>
>

Re: [Pharo-dev] help wanted: normalising LF on tonel for Pharo project

[Guillermo Polito]

Both, the checkbox will be used to set the property in disk at some point
:).

On Tue, Apr 10, 2018 at 11:55 PM, Esteban Lorenzano 
wrote:

> or a .iceberg file?
>
> Esteban
>
> ps: yep, we need it… we will have it, why not start now?
>
> On 10 Apr 2018, at 23:52, Guillermo Polito 
> wrote:
>
> It could be a checkbox in the "create repository dialog".
>
> "Use lf as default line ending"
>
> (and set it to true by default (?))
>
> On Tue, Apr 10, 2018 at 11:50 PM, Peter Uhnák  wrote:
>
>> An argument can be made that Pharo would _always_ produce LF.
>> I don't think I've ever needed _code_ to be CRLF in a ~decade of using
>> git on Windows. It was always just an annoyance.
>>
>> Peter
>>
>> On Tue, Apr 10, 2018 at 11:44 PM, Esteban Lorenzano 
>> wrote:
>>
>>> hi,
>>>
>>> > On 10 Apr 2018, at 23:17, Esteban A. Maringolo 
>>> wrote:
>>> >
>>> > Not stricly related, or maybe yes, but years ago in InfOil we started
>>> > using Dolphin Smalltalk PAX format[1] for packages with Git, and we
>>> used
>>> > that setting to store code in the repo, we didn't have any issues
>>> >
>>> > The .gitattributes contained this:
>>> > *.img binary
>>> > *.chg binary
>>> > *.sml binary
>>> > OurImage.img merge=ours
>>> > OurImage.chg merge=ours
>>> > *.pax eol=lf
>>> > *.cls eol=lf
>>> >
>>> > .pax was the "package definition" and "method extensions" (methods not
>>> > belonging to the package) file.
>>> > .cls was the 1 file per class+class-side used by this scheme
>>> >
>>> > Even we did everything in Windows for some reason I don't remember (+5
>>> > yrs ago) LF was better for Gitlab. What I also don't remember is if
>>> > during the checkout in the Gitlab CI some conversion was used or not. I
>>> > don't remember a lot of things, but I can ask them if you want.
>>> >
>>> > But I can confirm that this "trick" does work.
>>> >
>>> > Git for Windows even asks you if you want to automatically convert CRLF
>>> > to LF during checkin and back to CRLF on checkout.
>>>
>>> exactly what I want, because pharo/iceberg/tonel uses the system line
>>> ending to write the files :)
>>> thanks!
>>>
>>> Esteban
>>>
>>> ps: otherwise I will need to add some support in-image and I don’t think
>>> is the best approach.
>>> pps: now it remains to see if libgit2 honours the .gitattributes config
>>>
>>> >
>>> > Regards,
>>> >
>>> >
>>> > On 10/04/2018 18:05, Esteban Lorenzano wrote:
>>> >> Hi,
>>> >>
>>> >> I’ve been wondering how to better fix the problem of having windows
>>> and
>>> >> linux/macOS people contributing and the fact that files are written in
>>> >> their native system format (crlf windows, lf for the rest of the
>>> world).
>>> >>
>>> >> I digged a bit and I found a couple a link that helped me (after
>>> trying
>>> >> to understand the
>>> >> doc): https://stackoverflow.com/questions/170961/whats-the-best-cr
>>> lf-carriage-return-line-feed-handling-strategy-with-git
>>> >>
>>> >> and it seems adding a .gitattributes file with this content:
>>> >>
>>> >> # Auto detect text files and perform LF normalization
>>> >> *text=auto
>>> >> *.sttext merge=union eol=lf
>>> >>
>>> >> could fix the problem?
>>> >> can someone confirm this?
>>> >>
>>> >> (I confess this issue confuses me a lot :P)
>>> >>
>>> >> cheers!
>>> >> Esteban
>>> >
>>> > --
>>> > Esteban A. Maringolo
>>> >
>>>
>>>
>>>
>>
>
>
> --
>
> Guille Polito
> Research Engineer
>
>
> Centre de Recherche en Informatique, Signal et Automatique de Lille
> CRIStAL - UMR 9189
> French National Center for Scientific Research - *http://www.cnrs.fr
> *
>
> *Web:* *http://guillep.github.io* 
> *Phone: *+33 06 52 70 66 13
>
>
>


-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] help wanted: normalising LF on tonel for Pharo project

[Esteban Lorenzano]

or a .iceberg file?

Esteban

ps: yep, we need it… we will have it, why not start now?

> On 10 Apr 2018, at 23:52, Guillermo Polito  wrote:
> 
> It could be a checkbox in the "create repository dialog".
> 
> "Use lf as default line ending"
> 
> (and set it to true by default (?))
> 
> On Tue, Apr 10, 2018 at 11:50 PM, Peter Uhnák  > wrote:
> An argument can be made that Pharo would _always_ produce LF.
> I don't think I've ever needed _code_ to be CRLF in a ~decade of using git on 
> Windows. It was always just an annoyance.
> 
> Peter
> 
> On Tue, Apr 10, 2018 at 11:44 PM, Esteban Lorenzano  > wrote:
> hi,
> 
> > On 10 Apr 2018, at 23:17, Esteban A. Maringolo  > > wrote:
> >
> > Not stricly related, or maybe yes, but years ago in InfOil we started
> > using Dolphin Smalltalk PAX format[1] for packages with Git, and we used
> > that setting to store code in the repo, we didn't have any issues
> >
> > The .gitattributes contained this:
> > *.img binary
> > *.chg binary
> > *.sml binary
> > OurImage.img merge=ours
> > OurImage.chg merge=ours
> > *.pax eol=lf
> > *.cls eol=lf
> >
> > .pax was the "package definition" and "method extensions" (methods not
> > belonging to the package) file.
> > .cls was the 1 file per class+class-side used by this scheme
> >
> > Even we did everything in Windows for some reason I don't remember (+5
> > yrs ago) LF was better for Gitlab. What I also don't remember is if
> > during the checkout in the Gitlab CI some conversion was used or not. I
> > don't remember a lot of things, but I can ask them if you want.
> >
> > But I can confirm that this "trick" does work.
> >
> > Git for Windows even asks you if you want to automatically convert CRLF
> > to LF during checkin and back to CRLF on checkout.
> 
> exactly what I want, because pharo/iceberg/tonel uses the system line ending 
> to write the files :)
> thanks!
> 
> Esteban
> 
> ps: otherwise I will need to add some support in-image and I don’t think is 
> the best approach.
> pps: now it remains to see if libgit2 honours the .gitattributes config
> 
> >
> > Regards,
> >
> >
> > On 10/04/2018 18:05, Esteban Lorenzano wrote:
> >> Hi,
> >>
> >> I’ve been wondering how to better fix the problem of having windows and
> >> linux/macOS people contributing and the fact that files are written in
> >> their native system format (crlf windows, lf for the rest of the world).
> >>
> >> I digged a bit and I found a couple a link that helped me (after trying
> >> to understand the
> >> doc): 
> >> https://stackoverflow.com/questions/170961/whats-the-best-crlf-carriage-return-line-feed-handling-strategy-with-git
> >>  
> >> 
> >>
> >> and it seems adding a .gitattributes file with this content:
> >>
> >> # Auto detect text files and perform LF normalization
> >> *text=auto
> >> *.sttext merge=union eol=lf
> >>
> >> could fix the problem?
> >> can someone confirm this?
> >>
> >> (I confess this issue confuses me a lot :P)
> >>
> >> cheers!
> >> Esteban
> >
> > --
> > Esteban A. Maringolo
> >
> 
> 
> 
> 
> 
> 
> -- 
>
> Guille Polito
> Research Engineer
> 
> Centre de Recherche en Informatique, Signal et Automatique de Lille
> CRIStAL - UMR 9189
> French National Center for Scientific Research - http://www.cnrs.fr 
> 
> 
> Web: http://guillep.github.io 
> Phone: +33 06 52 70 66 13

Re: [Pharo-dev] Changed #atEnd primitive - #atEnd vs #next returning nil

[Sven Van Caekenberghe]

Alistair,

I am replying in-between, please don't take my remarks as being negative, I 
just like to straighten things out as clear as possible.

> On 10 Apr 2018, at 22:14, Alistair Grant  wrote:
> 
> Hi Sven,
> 
> On 10 April 2018 at 19:36, Sven Van Caekenberghe  wrote:
>> I have trouble understanding your problem analysis, and how your proposed 
>> solution, would solve it.
> 
> The discussion started with my proposal to modify the Zinc streams to
> check the return value of #next for nil rather than using #atEnd to
> iterate over the underlying stream.  You correctly pointed out that
> the intention behind #atEnd is that it can be used to control
> iterating over streams.

OK

>> Where is it being said that #next and/or #atEnd should be blocking or 
>> non-blocking ?
> 
> There is existing code that assumes that #atEnd is non-blocking and
> that #next is allowed block.  I believe that we should keep those
> conditions.

I fail to see where that is written down, either way. Can you point me to 
comments stating that, I would really like to know ?

>> How is this related to how EOF is signalled ?
> 
> Because, combined with terminal EOF not being known until the user
> explicitly flags it (with Ctrl-D) it means that #atEnd can't be used
> for iterating over input from stdin connected to a terminal.

This seems to me like an exception that only holds for one particular stream in 
one particular scenario (interactive stdin). I might be wrong.

>> It seems to me that there are quite a few classes of streams that are 
>> 'special' in the sense that #next could be blocking and/or #atEnd could be 
>> unclear - socket/network streams, serial streams, maybe stdio (interactive 
>> or not). Without a message like #isDataAvailable you cannot handle those 
>> without blocking.
> 
> Right.  I think this is a distraction (I was trying to explain some
> details, but it's causing more confusion instead of helping).
> 
> The important point is that #atEnd doesn't work for iterating over
> streams with terminal input

Maybe you should also point to the actual code that fails. I mean you showed a 
partial stack trace, but not how you got there, precisely. How does the 
application reading from an interactive stdin do to get into trouble ?

>> Reading from stdin seems like a very rare case for a Smalltalk system (not 
>> that it should not be possible).
> 
> There's been quite a bit of discussion and several projects recently
> related to using pharo for scripting, so it may become more common.
> E.g.
> 
> https://www.quora.com/Can-Smalltalk-be-a-batch-file-scripting-language/answer/Philippe-Back-1?share=c19bfc95
> https://github.com/rajula96reddy/pharo-cli

Still, it is not common at all.

>> I have a feeling that too much functionality is being pushed into too small 
>> an API.
> 
> This is just about how should Zinc streams be iterating over the
> underlying streams.  You didn't like checking the result of #next for
> nil since it isn't general, correctly pointing out that nil is a valid
> value for non-byte oriented streams.  But #atEnd doesn't work for
> stdin from a terminal.
> 
> 
> At this point I think there are three options:
> 
> 1. Modify Zinc to check the return value of #next instead of using #atEnd.
> 
> This is what all existing character / byte oriented streams in Squeak
> and Pharo do.  At that point the Zinc streams can be used on all file
> / stdio input and output.

I agree that such code exists in many places, but there is lots of stream 
reading that does not check for nils. 

> 2. Modify all streams to signal EOF in some other way, i.e. a sentinel
> or notification / exception.
> 
> This is what we were discussing below.  But it is a decent chunk of
> work with significant impact on the existing code base.

Agreed. This would be a future extension.

> 3. Require anyone who wants to read from stdin to code around Zinc's
> inability to handle terminal input.
> 
> I'd prefer to avoid this option if possible.

See higher for a more concrete usage example request. 

> Does that clarify the situation?

Yes, it helps. Thanks. But questions remain.

> Thanks,
> Alistair
> 
> 
> 
>>> On 10 Apr 2018, at 18:30, Alistair Grant  wrote:
>>> 
>>> First a quick update:
>>> 
>>> After doing some work on primitiveFileAtEnd, #atEnd now answers
>>> correctly for files that don't report their size correctly, e.g.
>>> /dev/urandom and /proc/cpuinfo, whether the files are opened directly or
>>> redirected through stdin.
>>> 
>>> However determining whether stdin from a terminal has reached the end of
>>> file can't be done without making #atEnd blocking since we have to wait
>>> for the user to flag the end of file, e.g. by typing Ctrl-D.  And #atEnd
>>> is assumed to be non-blocking.
>>> 
>>> So currently using ZnCharacterReadStream with stdin from a terminal will
>>> result in a stack dump similar to:
>>> 
>>> MessageNotUnderstood: receiver of "<" is nil
>>> 

Re: [Pharo-dev] help wanted: normalising LF on tonel for Pharo project

[Esteban Lorenzano]

> On 10 Apr 2018, at 23:47, Nicolai Hess  wrote:
> 
> How about
> 
> git config --system  core.autocrlf input
> 
> I use this in my opensmalltalk-vm git repository. (I think I saw this option 
> in the appveyor windows-vm build)

that may work too. 
but… I would like to also have a way to configure automatically that (in any 
case, please use it while the solution arrives).

Esteban

> 
> 2018-04-10 23:44 GMT+02:00 Esteban Lorenzano  >:
> hi,
> 
> > On 10 Apr 2018, at 23:17, Esteban A. Maringolo  > > wrote:
> >
> > Not stricly related, or maybe yes, but years ago in InfOil we started
> > using Dolphin Smalltalk PAX format[1] for packages with Git, and we used
> > that setting to store code in the repo, we didn't have any issues
> >
> > The .gitattributes contained this:
> > *.img binary
> > *.chg binary
> > *.sml binary
> > OurImage.img merge=ours
> > OurImage.chg merge=ours
> > *.pax eol=lf
> > *.cls eol=lf
> >
> > .pax was the "package definition" and "method extensions" (methods not
> > belonging to the package) file.
> > .cls was the 1 file per class+class-side used by this scheme
> >
> > Even we did everything in Windows for some reason I don't remember (+5
> > yrs ago) LF was better for Gitlab. What I also don't remember is if
> > during the checkout in the Gitlab CI some conversion was used or not. I
> > don't remember a lot of things, but I can ask them if you want.
> >
> > But I can confirm that this "trick" does work.
> >
> > Git for Windows even asks you if you want to automatically convert CRLF
> > to LF during checkin and back to CRLF on checkout.
> 
> exactly what I want, because pharo/iceberg/tonel uses the system line ending 
> to write the files :)
> thanks!
> 
> Esteban
> 
> ps: otherwise I will need to add some support in-image and I don’t think is 
> the best approach.
> pps: now it remains to see if libgit2 honours the .gitattributes config
> 
> >
> > Regards,
> >
> >
> > On 10/04/2018 18:05, Esteban Lorenzano wrote:
> >> Hi,
> >>
> >> I’ve been wondering how to better fix the problem of having windows and
> >> linux/macOS people contributing and the fact that files are written in
> >> their native system format (crlf windows, lf for the rest of the world).
> >>
> >> I digged a bit and I found a couple a link that helped me (after trying
> >> to understand the
> >> doc): 
> >> https://stackoverflow.com/questions/170961/whats-the-best-crlf-carriage-return-line-feed-handling-strategy-with-git
> >>  
> >> 
> >>
> >> and it seems adding a .gitattributes file with this content:
> >>
> >> # Auto detect text files and perform LF normalization
> >> *text=auto
> >> *.sttext merge=union eol=lf
> >>
> >> could fix the problem?
> >> can someone confirm this?
> >>
> >> (I confess this issue confuses me a lot :P)
> >>
> >> cheers!
> >> Esteban
> >
> > --
> > Esteban A. Maringolo
> >
> 
> 
> 

Re: [Pharo-dev] help wanted: normalising LF on tonel for Pharo project

[Guillermo Polito]

It could be a checkbox in the "create repository dialog".

"Use lf as default line ending"

(and set it to true by default (?))

On Tue, Apr 10, 2018 at 11:50 PM, Peter Uhnák  wrote:

> An argument can be made that Pharo would _always_ produce LF.
> I don't think I've ever needed _code_ to be CRLF in a ~decade of using git
> on Windows. It was always just an annoyance.
>
> Peter
>
> On Tue, Apr 10, 2018 at 11:44 PM, Esteban Lorenzano 
> wrote:
>
>> hi,
>>
>> > On 10 Apr 2018, at 23:17, Esteban A. Maringolo 
>> wrote:
>> >
>> > Not stricly related, or maybe yes, but years ago in InfOil we started
>> > using Dolphin Smalltalk PAX format[1] for packages with Git, and we used
>> > that setting to store code in the repo, we didn't have any issues
>> >
>> > The .gitattributes contained this:
>> > *.img binary
>> > *.chg binary
>> > *.sml binary
>> > OurImage.img merge=ours
>> > OurImage.chg merge=ours
>> > *.pax eol=lf
>> > *.cls eol=lf
>> >
>> > .pax was the "package definition" and "method extensions" (methods not
>> > belonging to the package) file.
>> > .cls was the 1 file per class+class-side used by this scheme
>> >
>> > Even we did everything in Windows for some reason I don't remember (+5
>> > yrs ago) LF was better for Gitlab. What I also don't remember is if
>> > during the checkout in the Gitlab CI some conversion was used or not. I
>> > don't remember a lot of things, but I can ask them if you want.
>> >
>> > But I can confirm that this "trick" does work.
>> >
>> > Git for Windows even asks you if you want to automatically convert CRLF
>> > to LF during checkin and back to CRLF on checkout.
>>
>> exactly what I want, because pharo/iceberg/tonel uses the system line
>> ending to write the files :)
>> thanks!
>>
>> Esteban
>>
>> ps: otherwise I will need to add some support in-image and I don’t think
>> is the best approach.
>> pps: now it remains to see if libgit2 honours the .gitattributes config
>>
>> >
>> > Regards,
>> >
>> >
>> > On 10/04/2018 18:05, Esteban Lorenzano wrote:
>> >> Hi,
>> >>
>> >> I’ve been wondering how to better fix the problem of having windows and
>> >> linux/macOS people contributing and the fact that files are written in
>> >> their native system format (crlf windows, lf for the rest of the
>> world).
>> >>
>> >> I digged a bit and I found a couple a link that helped me (after trying
>> >> to understand the
>> >> doc): https://stackoverflow.com/questions/170961/whats-the-best-
>> crlf-carriage-return-line-feed-handling-strategy-with-git
>> >>
>> >> and it seems adding a .gitattributes file with this content:
>> >>
>> >> # Auto detect text files and perform LF normalization
>> >> *text=auto
>> >> *.sttext merge=union eol=lf
>> >>
>> >> could fix the problem?
>> >> can someone confirm this?
>> >>
>> >> (I confess this issue confuses me a lot :P)
>> >>
>> >> cheers!
>> >> Esteban
>> >
>> > --
>> > Esteban A. Maringolo
>> >
>>
>>
>>
>


-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] help wanted: normalising LF on tonel for Pharo project

[Peter Uhnák]

An argument can be made that Pharo would _always_ produce LF.
I don't think I've ever needed _code_ to be CRLF in a ~decade of using git
on Windows. It was always just an annoyance.

Peter

On Tue, Apr 10, 2018 at 11:44 PM, Esteban Lorenzano 
wrote:

> hi,
>
> > On 10 Apr 2018, at 23:17, Esteban A. Maringolo 
> wrote:
> >
> > Not stricly related, or maybe yes, but years ago in InfOil we started
> > using Dolphin Smalltalk PAX format[1] for packages with Git, and we used
> > that setting to store code in the repo, we didn't have any issues
> >
> > The .gitattributes contained this:
> > *.img binary
> > *.chg binary
> > *.sml binary
> > OurImage.img merge=ours
> > OurImage.chg merge=ours
> > *.pax eol=lf
> > *.cls eol=lf
> >
> > .pax was the "package definition" and "method extensions" (methods not
> > belonging to the package) file.
> > .cls was the 1 file per class+class-side used by this scheme
> >
> > Even we did everything in Windows for some reason I don't remember (+5
> > yrs ago) LF was better for Gitlab. What I also don't remember is if
> > during the checkout in the Gitlab CI some conversion was used or not. I
> > don't remember a lot of things, but I can ask them if you want.
> >
> > But I can confirm that this "trick" does work.
> >
> > Git for Windows even asks you if you want to automatically convert CRLF
> > to LF during checkin and back to CRLF on checkout.
>
> exactly what I want, because pharo/iceberg/tonel uses the system line
> ending to write the files :)
> thanks!
>
> Esteban
>
> ps: otherwise I will need to add some support in-image and I don’t think
> is the best approach.
> pps: now it remains to see if libgit2 honours the .gitattributes config
>
> >
> > Regards,
> >
> >
> > On 10/04/2018 18:05, Esteban Lorenzano wrote:
> >> Hi,
> >>
> >> I’ve been wondering how to better fix the problem of having windows and
> >> linux/macOS people contributing and the fact that files are written in
> >> their native system format (crlf windows, lf for the rest of the world).
> >>
> >> I digged a bit and I found a couple a link that helped me (after trying
> >> to understand the
> >> doc): https://stackoverflow.com/questions/170961/whats-the-
> best-crlf-carriage-return-line-feed-handling-strategy-with-git
> >>
> >> and it seems adding a .gitattributes file with this content:
> >>
> >> # Auto detect text files and perform LF normalization
> >> *text=auto
> >> *.sttext merge=union eol=lf
> >>
> >> could fix the problem?
> >> can someone confirm this?
> >>
> >> (I confess this issue confuses me a lot :P)
> >>
> >> cheers!
> >> Esteban
> >
> > --
> > Esteban A. Maringolo
> >
>
>
>

Re: [Pharo-dev] help wanted: normalising LF on tonel for Pharo project

[Guillermo Polito]

I'd say yes?

https://github.com/libgit2/libgit2/commit/b83fd07880307106deb0ac7cb0d415d85c27f465

?

On Tue, Apr 10, 2018 at 11:42 PM, Guillermo Polito <
guillermopol...@gmail.com> wrote:

> Yes, that is the thing. Is libgit reading that properties file or not?
> I'll do some digging..
>
> On Tue, Apr 10, 2018 at 11:31 PM, Peter Uhnák  wrote:
>
>> > Git for Windows even asks you if you want to automatically convert CRLF
>> > to LF during checkin and back to CRLF on checkout.
>>
>> There are config options `core.eol` and `core.autocrlf`, but my
>> impression was that Iceberg was somehow bypassing them?
>>
>> Peter
>>
>>
>> On Tue, Apr 10, 2018 at 11:17 PM, Esteban A. Maringolo <
>> emaring...@gmail.com> wrote:
>>
>>> Not stricly related, or maybe yes, but years ago in InfOil we started
>>> using Dolphin Smalltalk PAX format[1] for packages with Git, and we used
>>> that setting to store code in the repo, we didn't have any issues
>>>
>>> The .gitattributes contained this:
>>> *.img binary
>>> *.chg binary
>>> *.sml binary
>>> OurImage.img merge=ours
>>> OurImage.chg merge=ours
>>> *.pax eol=lf
>>> *.cls eol=lf
>>>
>>> .pax was the "package definition" and "method extensions" (methods not
>>> belonging to the package) file.
>>> .cls was the 1 file per class+class-side used by this scheme
>>>
>>> Even we did everything in Windows for some reason I don't remember (+5
>>> yrs ago) LF was better for Gitlab. What I also don't remember is if
>>> during the checkout in the Gitlab CI some conversion was used or not. I
>>> don't remember a lot of things, but I can ask them if you want.
>>>
>>> But I can confirm that this "trick" does work.
>>>
>>> Git for Windows even asks you if you want to automatically convert CRLF
>>> to LF during checkin and back to CRLF on checkout.
>>>
>>> Regards,
>>>
>>>
>>> On 10/04/2018 18:05, Esteban Lorenzano wrote:
>>> > Hi,
>>> >
>>> > I’ve been wondering how to better fix the problem of having windows and
>>> > linux/macOS people contributing and the fact that files are written in
>>> > their native system format (crlf windows, lf for the rest of the
>>> world).
>>> >
>>> > I digged a bit and I found a couple a link that helped me (after trying
>>> > to understand the
>>> > doc): https://stackoverflow.com/questions/170961/whats-the-b
>>> est-crlf-carriage-return-line-feed-handling-strategy-with-git
>>> >
>>> > and it seems adding a .gitattributes file with this content:
>>> >
>>> > # Auto detect text files and perform LF normalization
>>> > *text=auto
>>> > *.sttext merge=union eol=lf
>>> >
>>> > could fix the problem?
>>> > can someone confirm this?
>>> >
>>> > (I confess this issue confuses me a lot :P)
>>> >
>>> > cheers!
>>> > Esteban
>>>
>>> --
>>> Esteban A. Maringolo
>>>
>>>
>>
>
>
> --
>
>
>
> Guille Polito
>
> Research Engineer
>
> Centre de Recherche en Informatique, Signal et Automatique de Lille
>
> CRIStAL - UMR 9189
>
> French National Center for Scientific Research - *http://www.cnrs.fr
> *
>
>
> *Web:* *http://guillep.github.io* 
>
> *Phone: *+33 06 52 70 66 13
>



-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] help wanted: normalising LF on tonel for Pharo project

[Nicolai Hess]

How about

git config --system  core.autocrlf input

I use this in my opensmalltalk-vm git repository. (I think I saw this
option in the appveyor windows-vm build)

2018-04-10 23:44 GMT+02:00 Esteban Lorenzano :

> hi,
>
> > On 10 Apr 2018, at 23:17, Esteban A. Maringolo 
> wrote:
> >
> > Not stricly related, or maybe yes, but years ago in InfOil we started
> > using Dolphin Smalltalk PAX format[1] for packages with Git, and we used
> > that setting to store code in the repo, we didn't have any issues
> >
> > The .gitattributes contained this:
> > *.img binary
> > *.chg binary
> > *.sml binary
> > OurImage.img merge=ours
> > OurImage.chg merge=ours
> > *.pax eol=lf
> > *.cls eol=lf
> >
> > .pax was the "package definition" and "method extensions" (methods not
> > belonging to the package) file.
> > .cls was the 1 file per class+class-side used by this scheme
> >
> > Even we did everything in Windows for some reason I don't remember (+5
> > yrs ago) LF was better for Gitlab. What I also don't remember is if
> > during the checkout in the Gitlab CI some conversion was used or not. I
> > don't remember a lot of things, but I can ask them if you want.
> >
> > But I can confirm that this "trick" does work.
> >
> > Git for Windows even asks you if you want to automatically convert CRLF
> > to LF during checkin and back to CRLF on checkout.
>
> exactly what I want, because pharo/iceberg/tonel uses the system line
> ending to write the files :)
> thanks!
>
> Esteban
>
> ps: otherwise I will need to add some support in-image and I don’t think
> is the best approach.
> pps: now it remains to see if libgit2 honours the .gitattributes config
>
> >
> > Regards,
> >
> >
> > On 10/04/2018 18:05, Esteban Lorenzano wrote:
> >> Hi,
> >>
> >> I’ve been wondering how to better fix the problem of having windows and
> >> linux/macOS people contributing and the fact that files are written in
> >> their native system format (crlf windows, lf for the rest of the world).
> >>
> >> I digged a bit and I found a couple a link that helped me (after trying
> >> to understand the
> >> doc): https://stackoverflow.com/questions/170961/whats-the-
> best-crlf-carriage-return-line-feed-handling-strategy-with-git
> >>
> >> and it seems adding a .gitattributes file with this content:
> >>
> >> # Auto detect text files and perform LF normalization
> >> *text=auto
> >> *.sttext merge=union eol=lf
> >>
> >> could fix the problem?
> >> can someone confirm this?
> >>
> >> (I confess this issue confuses me a lot :P)
> >>
> >> cheers!
> >> Esteban
> >
> > --
> > Esteban A. Maringolo
> >
>
>
>

Re: [Pharo-dev] Contribute a Fix and Reviewing changes

[Esteban Lorenzano]

> On 10 Apr 2018, at 23:37, Peter Uhnák  wrote:
> 
> Esteban, maybe (until the issue is properly resolved) Iceberg could have a 
> conditional check that the repo is pharo itself and just forced the output to 
> be LF?

yes, it could. 
I will add that tomorrow *if* libgit does not follow .gitattributes.

Esteban

> 
> Peter
> 
> On Tue, Apr 10, 2018 at 11:36 PM, Peter Uhnák  > wrote:
> Hi,
> 
> I --amend(ed) the commit after I converted it. If you've already pushed, you 
> can force-push (there's no one using your code yet, so forcing shouldn't be 
> an issue).
> If you have multiple commits, then you'd need to filter all the commits 
> (filter-branch iirc), so the newlines are correct in every single commit.
> 
> Peter
> 
> On Tue, Apr 10, 2018 at 11:31 PM, Nicolai Hess  > wrote:
> Ah!
> Ok.
> 
> 2018-04-10 23:26 GMT+02:00 Peter Uhnák  >:
> Hi,
> 
> did you commit on Windows? Because Iceberg seems to commit in 
> platform-specific line endings, so I always need to convert it manually... ( 
> https://github.com/PowerShell/Win32-OpenSSH/wiki/Dos2Unix---Text-file-format-converters
>  
> 
>  )
> 
> And how can I do this, if my changes are managed by iceberg ?
> Do I have to manually change the files in my local branch (right at my git 
> directory) and can I then still upload the fix from within iceberg?
>  
> 
> Notice also that all the files are from the same directory ... when you 
> commit even a single change, the entire package is filed out.
> 
> Peter
> 
> 
> 
> 
> On Tue, Apr 10, 2018 at 11:16 PM, Nicolai Hess  > wrote:
> Hi,
> 
> I tried to create a pull request with IceBerg.
> I followed the CONTRIBUTING HowTo and Markus' create TechTalk-Video.
> 
> But I must have done something wrong.
> This is my pull request:
> https://github.com/pharo-project/pharo/pull/1189 
> 
> But although I just changes one line in one method.
> The gitub pull request side shows 
> Commit 1 Files changed 40!
> But I did not change 40 files
> 
> 
> And I still have problems viewing pull requests from within pharo:
> 
> 
> 
> 
> 
> 
> I thought this would work meanwhil.
> 
> 
> Thanks in advance
> 
> nicolai
> 
> 
> 
> 
> 

Re: [Pharo-dev] help wanted: normalising LF on tonel for Pharo project

[Esteban Lorenzano]

hi,

> On 10 Apr 2018, at 23:17, Esteban A. Maringolo  wrote:
> 
> Not stricly related, or maybe yes, but years ago in InfOil we started
> using Dolphin Smalltalk PAX format[1] for packages with Git, and we used
> that setting to store code in the repo, we didn't have any issues
> 
> The .gitattributes contained this:
> *.img binary
> *.chg binary
> *.sml binary
> OurImage.img merge=ours
> OurImage.chg merge=ours
> *.pax eol=lf
> *.cls eol=lf
> 
> .pax was the "package definition" and "method extensions" (methods not
> belonging to the package) file.
> .cls was the 1 file per class+class-side used by this scheme
> 
> Even we did everything in Windows for some reason I don't remember (+5
> yrs ago) LF was better for Gitlab. What I also don't remember is if
> during the checkout in the Gitlab CI some conversion was used or not. I
> don't remember a lot of things, but I can ask them if you want.
> 
> But I can confirm that this "trick" does work.
> 
> Git for Windows even asks you if you want to automatically convert CRLF
> to LF during checkin and back to CRLF on checkout.

exactly what I want, because pharo/iceberg/tonel uses the system line ending to 
write the files :)
thanks!

Esteban

ps: otherwise I will need to add some support in-image and I don’t think is the 
best approach.
pps: now it remains to see if libgit2 honours the .gitattributes config

> 
> Regards,
> 
> 
> On 10/04/2018 18:05, Esteban Lorenzano wrote:
>> Hi, 
>> 
>> I’ve been wondering how to better fix the problem of having windows and
>> linux/macOS people contributing and the fact that files are written in
>> their native system format (crlf windows, lf for the rest of the world). 
>> 
>> I digged a bit and I found a couple a link that helped me (after trying
>> to understand the
>> doc): 
>> https://stackoverflow.com/questions/170961/whats-the-best-crlf-carriage-return-line-feed-handling-strategy-with-git
>> 
>> and it seems adding a .gitattributes file with this content: 
>> 
>> # Auto detect text files and perform LF normalization
>> *text=auto
>> *.sttext merge=union eol=lf
>> 
>> could fix the problem?
>> can someone confirm this?
>> 
>> (I confess this issue confuses me a lot :P)
>> 
>> cheers!
>> Esteban
> 
> -- 
> Esteban A. Maringolo
> 

Re: [Pharo-dev] help wanted: normalising LF on tonel for Pharo project

[Guillermo Polito]

Yes, that is the thing. Is libgit reading that properties file or not? I'll
do some digging..

On Tue, Apr 10, 2018 at 11:31 PM, Peter Uhnák  wrote:

> > Git for Windows even asks you if you want to automatically convert CRLF
> > to LF during checkin and back to CRLF on checkout.
>
> There are config options `core.eol` and `core.autocrlf`, but my impression
> was that Iceberg was somehow bypassing them?
>
> Peter
>
>
> On Tue, Apr 10, 2018 at 11:17 PM, Esteban A. Maringolo <
> emaring...@gmail.com> wrote:
>
>> Not stricly related, or maybe yes, but years ago in InfOil we started
>> using Dolphin Smalltalk PAX format[1] for packages with Git, and we used
>> that setting to store code in the repo, we didn't have any issues
>>
>> The .gitattributes contained this:
>> *.img binary
>> *.chg binary
>> *.sml binary
>> OurImage.img merge=ours
>> OurImage.chg merge=ours
>> *.pax eol=lf
>> *.cls eol=lf
>>
>> .pax was the "package definition" and "method extensions" (methods not
>> belonging to the package) file.
>> .cls was the 1 file per class+class-side used by this scheme
>>
>> Even we did everything in Windows for some reason I don't remember (+5
>> yrs ago) LF was better for Gitlab. What I also don't remember is if
>> during the checkout in the Gitlab CI some conversion was used or not. I
>> don't remember a lot of things, but I can ask them if you want.
>>
>> But I can confirm that this "trick" does work.
>>
>> Git for Windows even asks you if you want to automatically convert CRLF
>> to LF during checkin and back to CRLF on checkout.
>>
>> Regards,
>>
>>
>> On 10/04/2018 18:05, Esteban Lorenzano wrote:
>> > Hi,
>> >
>> > I’ve been wondering how to better fix the problem of having windows and
>> > linux/macOS people contributing and the fact that files are written in
>> > their native system format (crlf windows, lf for the rest of the
>> world).
>> >
>> > I digged a bit and I found a couple a link that helped me (after trying
>> > to understand the
>> > doc): https://stackoverflow.com/questions/170961/whats-the-
>> best-crlf-carriage-return-line-feed-handling-strategy-with-git
>> >
>> > and it seems adding a .gitattributes file with this content:
>> >
>> > # Auto detect text files and perform LF normalization
>> > *text=auto
>> > *.sttext merge=union eol=lf
>> >
>> > could fix the problem?
>> > can someone confirm this?
>> >
>> > (I confess this issue confuses me a lot :P)
>> >
>> > cheers!
>> > Esteban
>>
>> --
>> Esteban A. Maringolo
>>
>>
>


-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Contribute a Fix and Reviewing changes

[Peter Uhnák]

Esteban, maybe (until the issue is properly resolved) Iceberg could have a
conditional check that the repo is pharo itself and just forced the output
to be LF?

Peter

On Tue, Apr 10, 2018 at 11:36 PM, Peter Uhnák  wrote:

> Hi,
>
> I --amend(ed) the commit after I converted it. If you've already pushed,
> you can force-push (there's no one using your code yet, so forcing
> shouldn't be an issue).
> If you have multiple commits, then you'd need to filter all the commits
> (filter-branch iirc), so the newlines are correct in every single commit.
>
> Peter
>
> On Tue, Apr 10, 2018 at 11:31 PM, Nicolai Hess 
> wrote:
>
>> Ah!
>> Ok.
>>
>> 2018-04-10 23:26 GMT+02:00 Peter Uhnák :
>>
>>> Hi,
>>>
>>> did you commit on Windows? Because Iceberg seems to commit in
>>> platform-specific line endings, so I always need to convert it manually...
>>> ( https://github.com/PowerShell/Win32-OpenSSH/wiki/Dos2Unix-
>>> --Text-file-format-converters )
>>>
>>
>> And how can I do this, if my changes are managed by iceberg ?
>> Do I have to manually change the files in my local branch (right at my
>> git directory) and can I then still upload the fix from within iceberg?
>>
>>
>>>
>>> Notice also that all the files are from the same directory ... when you
>>> commit even a single change, the entire package is filed out.
>>>
>>> Peter
>>>
>>>
>>>
>>>
>>> On Tue, Apr 10, 2018 at 11:16 PM, Nicolai Hess 
>>> wrote:
>>>
 Hi,

 I tried to create a pull request with IceBerg.
 I followed the CONTRIBUTING HowTo and Markus' create TechTalk-Video.

 But I must have done something wrong.
 This is my pull request:
 https://github.com/pharo-project/pharo/pull/1189
 But although I just changes one line in one method.
 The gitub pull request side shows
 Commit 1 Files changed 40!
 But I did not change 40 files


 And I still have problems viewing pull requests from within pharo:






 I thought this would work meanwhil.


 Thanks in advance

 nicolai


>>>
>>
>

Re: [Pharo-dev] Contribute a Fix and Reviewing changes

[Peter Uhnák]

Hi,

I --amend(ed) the commit after I converted it. If you've already pushed,
you can force-push (there's no one using your code yet, so forcing
shouldn't be an issue).
If you have multiple commits, then you'd need to filter all the commits
(filter-branch iirc), so the newlines are correct in every single commit.

Peter

On Tue, Apr 10, 2018 at 11:31 PM, Nicolai Hess 
wrote:

> Ah!
> Ok.
>
> 2018-04-10 23:26 GMT+02:00 Peter Uhnák :
>
>> Hi,
>>
>> did you commit on Windows? Because Iceberg seems to commit in
>> platform-specific line endings, so I always need to convert it manually...
>> ( https://github.com/PowerShell/Win32-OpenSSH/wiki/Dos2Unix-
>> --Text-file-format-converters )
>>
>
> And how can I do this, if my changes are managed by iceberg ?
> Do I have to manually change the files in my local branch (right at my git
> directory) and can I then still upload the fix from within iceberg?
>
>
>>
>> Notice also that all the files are from the same directory ... when you
>> commit even a single change, the entire package is filed out.
>>
>> Peter
>>
>>
>>
>>
>> On Tue, Apr 10, 2018 at 11:16 PM, Nicolai Hess 
>> wrote:
>>
>>> Hi,
>>>
>>> I tried to create a pull request with IceBerg.
>>> I followed the CONTRIBUTING HowTo and Markus' create TechTalk-Video.
>>>
>>> But I must have done something wrong.
>>> This is my pull request:
>>> https://github.com/pharo-project/pharo/pull/1189
>>> But although I just changes one line in one method.
>>> The gitub pull request side shows
>>> Commit 1 Files changed 40!
>>> But I did not change 40 files
>>>
>>>
>>> And I still have problems viewing pull requests from within pharo:
>>>
>>>
>>>
>>>
>>>
>>>
>>> I thought this would work meanwhil.
>>>
>>>
>>> Thanks in advance
>>>
>>> nicolai
>>>
>>>
>>
>

Re: [Pharo-dev] Contribute a Fix and Reviewing changes

[Esteban Lorenzano]

yes, that’s why I asked about the problem with line endings. 

I will solve it, heh… don’t worry. 

In the mean time I will fix the PR tomorrow.

Esteban

> On 10 Apr 2018, at 23:31, Nicolai Hess  wrote:
> 
> Ah!
> Ok.
> 
> 2018-04-10 23:26 GMT+02:00 Peter Uhnák  >:
> Hi,
> 
> did you commit on Windows? Because Iceberg seems to commit in 
> platform-specific line endings, so I always need to convert it manually... ( 
> https://github.com/PowerShell/Win32-OpenSSH/wiki/Dos2Unix---Text-file-format-converters
>  
> 
>  )
> 
> And how can I do this, if my changes are managed by iceberg ?
> Do I have to manually change the files in my local branch (right at my git 
> directory) and can I then still upload the fix from within iceberg?
>  
> 
> Notice also that all the files are from the same directory ... when you 
> commit even a single change, the entire package is filed out.
> 
> Peter
> 
> 
> 
> 
> On Tue, Apr 10, 2018 at 11:16 PM, Nicolai Hess  > wrote:
> Hi,
> 
> I tried to create a pull request with IceBerg.
> I followed the CONTRIBUTING HowTo and Markus' create TechTalk-Video.
> 
> But I must have done something wrong.
> This is my pull request:
> https://github.com/pharo-project/pharo/pull/1189 
> 
> But although I just changes one line in one method.
> The gitub pull request side shows 
> Commit 1 Files changed 40!
> But I did not change 40 files
> 
> 
> And I still have problems viewing pull requests from within pharo:
> 
> 
> 
> 
> 
> 
> I thought this would work meanwhil.
> 
> 
> Thanks in advance
> 
> nicolai
> 
> 
> 

Re: [Pharo-dev] help wanted: normalising LF on tonel for Pharo project

[Peter Uhnák]

> Git for Windows even asks you if you want to automatically convert CRLF
> to LF during checkin and back to CRLF on checkout.

There are config options `core.eol` and `core.autocrlf`, but my impression
was that Iceberg was somehow bypassing them?

Peter


On Tue, Apr 10, 2018 at 11:17 PM, Esteban A. Maringolo  wrote:

> Not stricly related, or maybe yes, but years ago in InfOil we started
> using Dolphin Smalltalk PAX format[1] for packages with Git, and we used
> that setting to store code in the repo, we didn't have any issues
>
> The .gitattributes contained this:
> *.img binary
> *.chg binary
> *.sml binary
> OurImage.img merge=ours
> OurImage.chg merge=ours
> *.pax eol=lf
> *.cls eol=lf
>
> .pax was the "package definition" and "method extensions" (methods not
> belonging to the package) file.
> .cls was the 1 file per class+class-side used by this scheme
>
> Even we did everything in Windows for some reason I don't remember (+5
> yrs ago) LF was better for Gitlab. What I also don't remember is if
> during the checkout in the Gitlab CI some conversion was used or not. I
> don't remember a lot of things, but I can ask them if you want.
>
> But I can confirm that this "trick" does work.
>
> Git for Windows even asks you if you want to automatically convert CRLF
> to LF during checkin and back to CRLF on checkout.
>
> Regards,
>
>
> On 10/04/2018 18:05, Esteban Lorenzano wrote:
> > Hi,
> >
> > I’ve been wondering how to better fix the problem of having windows and
> > linux/macOS people contributing and the fact that files are written in
> > their native system format (crlf windows, lf for the rest of the world).
> >
> > I digged a bit and I found a couple a link that helped me (after trying
> > to understand the
> > doc): https://stackoverflow.com/questions/170961/whats-
> the-best-crlf-carriage-return-line-feed-handling-strategy-with-git
> >
> > and it seems adding a .gitattributes file with this content:
> >
> > # Auto detect text files and perform LF normalization
> > *text=auto
> > *.sttext merge=union eol=lf
> >
> > could fix the problem?
> > can someone confirm this?
> >
> > (I confess this issue confuses me a lot :P)
> >
> > cheers!
> > Esteban
>
> --
> Esteban A. Maringolo
>
>

Re: [Pharo-dev] Contribute a Fix and Reviewing changes

[Nicolai Hess]

Ah!
Ok.

2018-04-10 23:26 GMT+02:00 Peter Uhnák :

> Hi,
>
> did you commit on Windows? Because Iceberg seems to commit in
> platform-specific line endings, so I always need to convert it manually...
> ( https://github.com/PowerShell/Win32-OpenSSH/wiki/
> Dos2Unix---Text-file-format-converters )
>

And how can I do this, if my changes are managed by iceberg ?
Do I have to manually change the files in my local branch (right at my git
directory) and can I then still upload the fix from within iceberg?


>
> Notice also that all the files are from the same directory ... when you
> commit even a single change, the entire package is filed out.
>
> Peter
>
>
>
>
> On Tue, Apr 10, 2018 at 11:16 PM, Nicolai Hess 
> wrote:
>
>> Hi,
>>
>> I tried to create a pull request with IceBerg.
>> I followed the CONTRIBUTING HowTo and Markus' create TechTalk-Video.
>>
>> But I must have done something wrong.
>> This is my pull request:
>> https://github.com/pharo-project/pharo/pull/1189
>> But although I just changes one line in one method.
>> The gitub pull request side shows
>> Commit 1 Files changed 40!
>> But I did not change 40 files
>>
>>
>> And I still have problems viewing pull requests from within pharo:
>>
>>
>>
>>
>>
>>
>> I thought this would work meanwhil.
>>
>>
>> Thanks in advance
>>
>> nicolai
>>
>>
>

Re: [Pharo-dev] Contribute a Fix and Reviewing changes

[Peter Uhnák]

Hi,

did you commit on Windows? Because Iceberg seems to commit in
platform-specific line endings, so I always need to convert it manually...
(
https://github.com/PowerShell/Win32-OpenSSH/wiki/Dos2Unix---Text-file-format-converters
)

Notice also that all the files are from the same directory ... when you
commit even a single change, the entire package is filed out.

Peter




On Tue, Apr 10, 2018 at 11:16 PM, Nicolai Hess 
wrote:

> Hi,
>
> I tried to create a pull request with IceBerg.
> I followed the CONTRIBUTING HowTo and Markus' create TechTalk-Video.
>
> But I must have done something wrong.
> This is my pull request:
> https://github.com/pharo-project/pharo/pull/1189
> But although I just changes one line in one method.
> The gitub pull request side shows
> Commit 1 Files changed 40!
> But I did not change 40 files
>
>
> And I still have problems viewing pull requests from within pharo:
>
>
>
>
>
>
> I thought this would work meanwhil.
>
>
> Thanks in advance
>
> nicolai
>
>

Re: [Pharo-dev] call for help: answer on HN :)

[Damien Pollet]

There's a talk on the state of Clojure which I think resonates a lot with
what we're experiencing in Pharo:
https://www.youtube.com/watch?v=1YCkOo5Y4Oo
Spoiler: he concludes it's better to contribute and discuss issues than to
be all sad and bitter :-)

On 10 April 2018 at 17:37, Sean P. DeNigris  wrote:

> philippeback wrote
> > Who would have envisioned the Pharo of today in the beginning?
> > I am thankful for Pharo, trolls be damned.
>
> Absolutely agree!!
>
>
>
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>
>


-- 
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

Re: [Pharo-dev] help wanted: normalising LF on tonel for Pharo project

[Esteban A. Maringolo]

Not stricly related, or maybe yes, but years ago in InfOil we started
using Dolphin Smalltalk PAX format[1] for packages with Git, and we used
that setting to store code in the repo, we didn't have any issues

The .gitattributes contained this:
*.img binary
*.chg binary
*.sml binary
OurImage.img merge=ours
OurImage.chg merge=ours
*.pax eol=lf
*.cls eol=lf

.pax was the "package definition" and "method extensions" (methods not
belonging to the package) file.
.cls was the 1 file per class+class-side used by this scheme

Even we did everything in Windows for some reason I don't remember (+5
yrs ago) LF was better for Gitlab. What I also don't remember is if
during the checkout in the Gitlab CI some conversion was used or not. I
don't remember a lot of things, but I can ask them if you want.

But I can confirm that this "trick" does work.

Git for Windows even asks you if you want to automatically convert CRLF
to LF during checkin and back to CRLF on checkout.

Regards,


On 10/04/2018 18:05, Esteban Lorenzano wrote:
> Hi, 
> 
> I’ve been wondering how to better fix the problem of having windows and
> linux/macOS people contributing and the fact that files are written in
> their native system format (crlf windows, lf for the rest of the world). 
> 
> I digged a bit and I found a couple a link that helped me (after trying
> to understand the
> doc): 
> https://stackoverflow.com/questions/170961/whats-the-best-crlf-carriage-return-line-feed-handling-strategy-with-git
> 
> and it seems adding a .gitattributes file with this content: 
> 
> # Auto detect text files and perform LF normalization
> *text=auto
> *.sttext merge=union eol=lf
> 
> could fix the problem?
> can someone confirm this?
> 
> (I confess this issue confuses me a lot :P)
> 
> cheers!
> Esteban

-- 
Esteban A. Maringolo

[Pharo-dev] Contribute a Fix and Reviewing changes

[Nicolai Hess]

Hi,

I tried to create a pull request with IceBerg.
I followed the CONTRIBUTING HowTo and Markus' create TechTalk-Video.

But I must have done something wrong.
This is my pull request:
https://github.com/pharo-project/pharo/pull/1189
But although I just changes one line in one method.
The gitub pull request side shows
Commit 1 Files changed 40!
But I did not change 40 files


And I still have problems viewing pull requests from within pharo:






I thought this would work meanwhil.


Thanks in advance

nicolai

[Pharo-dev] help wanted: normalising LF on tonel for Pharo project

[Esteban Lorenzano]

Hi, 

I’ve been wondering how to better fix the problem of having windows and 
linux/macOS people contributing and the fact that files are written in their 
native system format (crlf windows, lf for the rest of the world). 

I digged a bit and I found a couple a link that helped me (after trying to 
understand the doc): 
https://stackoverflow.com/questions/170961/whats-the-best-crlf-carriage-return-line-feed-handling-strategy-with-git
 


and it seems adding a .gitattributes file with this content: 

# Auto detect text files and perform LF normalization
*   text=auto
*.sttext merge=union eol=lf

could fix the problem?
can someone confirm this?

(I confess this issue confuses me a lot :P)

cheers!
Esteban

Re: [Pharo-dev] Changed #atEnd primitive - #atEnd vs #next returning nil

[Alistair Grant]

Hi Sven,

On 10 April 2018 at 19:36, Sven Van Caekenberghe  wrote:
> I have trouble understanding your problem analysis, and how your proposed 
> solution, would solve it.

The discussion started with my proposal to modify the Zinc streams to
check the return value of #next for nil rather than using #atEnd to
iterate over the underlying stream.  You correctly pointed out that
the intention behind #atEnd is that it can be used to control
iterating over streams.


> Where is it being said that #next and/or #atEnd should be blocking or 
> non-blocking ?

There is existing code that assumes that #atEnd is non-blocking and
that #next is allowed block.  I believe that we should keep those
conditions.


> How is this related to how EOF is signalled ?

Because, combined with terminal EOF not being known until the user
explicitly flags it (with Ctrl-D) it means that #atEnd can't be used
for iterating over input from stdin connected to a terminal.



> It seems to me that there are quite a few classes of streams that are 
> 'special' in the sense that #next could be blocking and/or #atEnd could be 
> unclear - socket/network streams, serial streams, maybe stdio (interactive or 
> not). Without a message like #isDataAvailable you cannot handle those without 
> blocking.

Right.  I think this is a distraction (I was trying to explain some
details, but it's causing more confusion instead of helping).

The important point is that #atEnd doesn't work for iterating over
streams with terminal input



> Reading from stdin seems like a very rare case for a Smalltalk system (not 
> that it should not be possible).

There's been quite a bit of discussion and several projects recently
related to using pharo for scripting, so it may become more common.
E.g.

https://www.quora.com/Can-Smalltalk-be-a-batch-file-scripting-language/answer/Philippe-Back-1?share=c19bfc95
https://github.com/rajula96reddy/pharo-cli



> I have a feeling that too much functionality is being pushed into too small 
> an API.


This is just about how should Zinc streams be iterating over the
underlying streams.  You didn't like checking the result of #next for
nil since it isn't general, correctly pointing out that nil is a valid
value for non-byte oriented streams.  But #atEnd doesn't work for
stdin from a terminal.


At this point I think there are three options:

1. Modify Zinc to check the return value of #next instead of using #atEnd.

This is what all existing character / byte oriented streams in Squeak
and Pharo do.  At that point the Zinc streams can be used on all file
/ stdio input and output.


2. Modify all streams to signal EOF in some other way, i.e. a sentinel
or notification / exception.

This is what we were discussing below.  But it is a decent chunk of
work with significant impact on the existing code base.


3. Require anyone who wants to read from stdin to code around Zinc's
inability to handle terminal input.

I'd prefer to avoid this option if possible.


Does that clarify the situation?

Thanks,
Alistair



>> On 10 Apr 2018, at 18:30, Alistair Grant  wrote:
>>
>> First a quick update:
>>
>> After doing some work on primitiveFileAtEnd, #atEnd now answers
>> correctly for files that don't report their size correctly, e.g.
>> /dev/urandom and /proc/cpuinfo, whether the files are opened directly or
>> redirected through stdin.
>>
>> However determining whether stdin from a terminal has reached the end of
>> file can't be done without making #atEnd blocking since we have to wait
>> for the user to flag the end of file, e.g. by typing Ctrl-D.  And #atEnd
>> is assumed to be non-blocking.
>>
>> So currently using ZnCharacterReadStream with stdin from a terminal will
>> result in a stack dump similar to:
>>
>> MessageNotUnderstood: receiver of "<" is nil
>> UndefinedObject(Object)>>doesNotUnderstand: #<
>> ZnUTF8Encoder>>nextCodePointFromStream:
>> ZnUTF8Encoder(ZnCharacterEncoder)>>nextFromStream:
>> ZnCharacterReadStream>>nextElement
>> ZnCharacterReadStream(ZnEncodedReadStream)>>next
>> UndefinedObject>>DoIt
>>
>>
>> Going back through the various suggestions that have been made regarding
>> using a sentinel object vs. raising a notification / exception, my
>> (still to be polished) suggestion is to:
>>
>> 1. Add an endOfStream instance variable
>> 2. When the end of the stream is reached answer the value of the
>>   instance variable (i.e. the result of sending #value to the variable).
>> 3. The initial default value would be a block that raises a Deprecation
>>   warning and then returns nil.  This would allow existing code to
>>   function for a changeover period.
>> 4. At the end of the deprecation period the default value would be
>>   changed to a unique sentinel object which would answer itself as its
>>   #value.
>>
>> At any time users of the stream can set their own sentinel, including a
>> block that raises an exception.
>>
>>
>> Cheers,
>> Alistair
>>
>>
>> On 4 April 2018 at 19:24, 

Re: [Pharo-dev] Executive Programming

[askoh]

Ben:

I have been thinking along the same lines. 
Smalltalk is my PersonalOS.

Instead of *.bat or *.sh files, I would use Smalltalk to call OS commands
directly in methods to do what I want in the OS while using Smalltalk to do
the logic. PersonalOS should be able to run on multiple OS's using the same
methods to do the same things. So, an easy interface to OS commands and
possibly OS APIs would encourage people to use Smalltalk for controlling
everything else. Smalltalk would be the center of control and automation
from individuals to corporations and beyond.

Hopefully, we can get critical mass with this.

Aik-Siong Koh



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

[Eliot Miranda]

Hi Sven,

On Tue, Apr 10, 2018 at 7:33 AM, Sven Van Caekenberghe  wrote:

>
>
> > On 10 Apr 2018, at 16:13, Stephane Ducasse 
> wrote:
> >
> > What is a field based date and  time?
>
> This is more of an implementation choice but it has probably influence on
> the API as well.
>
> Field based date/time/datetime objects are like the naive implementation
> where each element that we talk about as humans has its own instance
> variable. You would store hours, minutes, seconds, nanosecond separately,
> as well as year, month, day.
>
> This is not as efficient as the current implementations, where time is
> typically stored as seconds and nanoseconds, and dates as a single julian
> day number.
>
> Still, these are implementation choices. For example, the split between
> seconds and nanoseconds is a bit artificial as well (it is so that both
> remain SmallIntegers in 32-bit), while in 64-bit this decision could be
> revised.
>

Note that the VM provides times as either 64-bit LargePositiveInteger
microseconds from 1901 (32-bits) or 61-bit positive SmallInteger
microseconds from 1901 (64-bits), in either UTC or the current time zone.

This gives us the following fit-for-purpose limits:

DateAndTime fromSeconds: 1 << 64 - 1 // 100 586455-01-18T08:01:49-07:00
DateAndTime fromSeconds: SmallInteger maxVal // 100
38435-08-17T21:30:06-07:00

Choosing 64-bit nanoseconds doesn't work nearly as well; we run out of bits
in 586 years.

I don't buy the performance issue of keeping things as SmallIntegers.
There is good 64-bit positive integer support in all the 32-bit VMs (e.g.
in the interpreter, inlined #+. #- et al all work on a 64-bit integer
range).  If Pharo does decide to change the internal representation then I
suggest that it uses the same representation as the VM.


> > On Tue, Apr 10, 2018 at 1:32 PM, Esteban A. Maringolo
> >  wrote:
> >>
> >> What is missing in the current Pharo image is a field based
> >> Date/DateTime instead of an offset+duration one as it currently is.
> >>
> >> Why not use Chronos instead? AFAIR Chronos provides that.
> >>
> >> An alternative would be to implement a "Calendar" (as in
> >> Java.util.Calendar [1]), that can exist in parallel with the existing
> >> Date class.
> >>
> >> Regards,
> >>
> >> [1] https://developer.android.com/reference/java/util/Calendar.html
> >>
> >> On 10/04/2018 03:30, Stephane Ducasse wrote:
> >>> Hi Paul
> >>>
> >>> I agree and instead of patching the current system I would start using
> >>> TDD to design
> >>> a new Date package.
> >>>
> >>> stef
> >>>
> >>> On Mon, Apr 9, 2018 at 8:42 PM, Paul DeBruicker 
> wrote:
>  I  think #= is a bad selector for Date and should be avoided when
> determining
>  whether something happens on a date, or whether two dates are the
> same.   We
>  all know March 24th in London covers a different 24 hours than March
> 24th in
>  Hawaii but Date>>#= does not.
> 
> 
> 
>  I think whats needed are more descriptive selectors like
> 
> 
>  Date>>#isSameOnDateAs: aDateOrDateAndTime
>  Date>>#overlapsWithDate: aDate
>  DateAndTime>>#occursOnDate: aDate
>  DateAndTime>>#sameHMSButDifferentUTCIn: aTimeZoneKey
>  DateAndTime>>#sameUTCButDifferentHMSIn: aTimeZoneKey
> 
>  and change Date>>#= to #shouldNotImplement.
> 
> 
>  FWIW I also don't like #offset: as before you send it you know the
> timezone
>  and after you may let that knowledge be forgotten. Real offsets can
> change
>  as laws change.
> 
> 
> 
>  I think people are aware of this but if you have need for comparing
> dates &
>  times then you must use a library that accesses the regularly updated
> Olson
>  timezone database on your system and classes that respect time
> zones.  Time
>  zones are political, and legal definitions of offsets can change hours
>  before the DST transition dates & times.
> 
> 
>  I don't think it matters which default timezone you pick for the
> image if
>  you're not going to take them into account when doing comparisons.
> 
> 
>  Unfortunately there isn't a way to avoid this complexity until DST
> goes
>  away.
> 
> 
>  There's certainly flaws to how we currently do it and I think
>  TimeZoneDatabase and Chronos make good attempts to fix it.  I haven't
> looked
>  at Chalten but would guess its good too.
> 
> 
> 
> 
> 
> 
> 
> 
>  Sean P. DeNigris wrote
> > I was bitten by this very annoying bug again. As most of us probably
> know
> > due
> > to the steady stream of confused ML posts in the past, the bug in
> summary
> > is
> > that we have an incomplete timezone implementation that doesn't
> properly
> > take into account historical DST changes. This flares up without
> warning
> > especially when DST toggles. I created a 

Re: [Pharo-dev] Changed #atEnd primitive - #atEnd vs #next returning nil

[Sven Van Caekenberghe]

I have trouble understanding your problem analysis, and how your proposed 
solution, would solve it.

Where is it being said that #next and/or #atEnd should be blocking or 
non-blocking ?
How is this related to how EOF is signalled ?

It seems to me that there are quite a few classes of streams that are 'special' 
in the sense that #next could be blocking and/or #atEnd could be unclear - 
socket/network streams, serial streams, maybe stdio (interactive or not). 
Without a message like #isDataAvailable you cannot handle those without 
blocking.

Reading from stdin seems like a very rare case for a Smalltalk system (not that 
it should not be possible).

I have a feeling that too much functionality is being pushed into too small an 
API.

> On 10 Apr 2018, at 18:30, Alistair Grant  wrote:
> 
> First a quick update:
> 
> After doing some work on primitiveFileAtEnd, #atEnd now answers
> correctly for files that don't report their size correctly, e.g.
> /dev/urandom and /proc/cpuinfo, whether the files are opened directly or
> redirected through stdin.
> 
> However determining whether stdin from a terminal has reached the end of
> file can't be done without making #atEnd blocking since we have to wait
> for the user to flag the end of file, e.g. by typing Ctrl-D.  And #atEnd
> is assumed to be non-blocking.
> 
> So currently using ZnCharacterReadStream with stdin from a terminal will
> result in a stack dump similar to:
> 
> MessageNotUnderstood: receiver of "<" is nil
> UndefinedObject(Object)>>doesNotUnderstand: #<
> ZnUTF8Encoder>>nextCodePointFromStream:
> ZnUTF8Encoder(ZnCharacterEncoder)>>nextFromStream:
> ZnCharacterReadStream>>nextElement
> ZnCharacterReadStream(ZnEncodedReadStream)>>next
> UndefinedObject>>DoIt
> 
> 
> Going back through the various suggestions that have been made regarding
> using a sentinel object vs. raising a notification / exception, my
> (still to be polished) suggestion is to:
> 
> 1. Add an endOfStream instance variable
> 2. When the end of the stream is reached answer the value of the
>   instance variable (i.e. the result of sending #value to the variable).
> 3. The initial default value would be a block that raises a Deprecation
>   warning and then returns nil.  This would allow existing code to
>   function for a changeover period.
> 4. At the end of the deprecation period the default value would be
>   changed to a unique sentinel object which would answer itself as its
>   #value.
> 
> At any time users of the stream can set their own sentinel, including a
> block that raises an exception.
> 
> 
> Cheers,
> Alistair
> 
> 
> On 4 April 2018 at 19:24, Stephane Ducasse  wrote:
>> Thanks for this discussion.
>> 
>> On Wed, Apr 4, 2018 at 1:37 PM, Sven Van Caekenberghe  wrote:
>>> Alistair,
>>> 
>>> First off, thanks for the discussions and your contributions, I really 
>>> appreciate them.
>>> 
>>> But I want to have a discussion at the high level of the definition and 
>>> semantics of the stream API in Pharo.
>>> 
 On 4 Apr 2018, at 13:20, Alistair Grant  wrote:
 
 On 4 April 2018 at 12:56, Sven Van Caekenberghe  wrote:
> Playing a bit devil's advocate, the idea is that, in general,
> 
> [ stream atEnd] whileFalse: [ stream next. "..." ].
> 
> is no longer allowed ?
 
 It hasn't been allowed "forever" [1].  It's just been misused for
 almost as long.
 
 [1] Time began when stdio stream support was introduced. :-)
>>> 
>>> I am still not convinced. Another way to put it would be that the old 
>>> #atEnd or #upToEnd do not make sense for these streams and some new loop is 
>>> needed, based on a new test (it exists for socket streams already).
>>> 
>>> [ stream isDataAvailable ] whileTrue: [ stream next ]
>>> 
> And you want to replace it with
> 
> [ stream next ifNil: [ false ] ifNotNil: [ :x | "..." true ] whileTrue.
> 
> That is a pretty big change, no ?
 
 That's the way quite a bit of code already operates.
 
 As Denis pointed out, it's obviously problematic in the general sense,
 since nil can be embedded in non-byte oriented streams.  I suspect
 that in practice not many people write code that reads streams from
 both byte oriented and non-byte oriented streams.
>>> 
>>> Maybe yes, maybe no. As Denis' example shows there is a clear definition 
>>> problem.
>>> 
>>> And I do use streams of byte arrays or strings all the time, this is really 
>>> important. I want my parsers to work on all kinds of streams.
>>> 
> I think/feel like a proper EOF exception would be better, more correct.
> 
> [ [ stream next. "..." true ] on: EOF do: [ false ] ] whileTrue.
 
 I agree, but the email thread Nicolas pointed to raises some
 performance questions about this approach.  It should be
 straightforward to do a basic performance comparison which I'll get
 

Re: [Pharo-dev] Changed #atEnd primitive - #atEnd vs #next returning nil

[Alistair Grant]

First a quick update:

After doing some work on primitiveFileAtEnd, #atEnd now answers
correctly for files that don't report their size correctly, e.g.
/dev/urandom and /proc/cpuinfo, whether the files are opened directly or
redirected through stdin.

However determining whether stdin from a terminal has reached the end of
file can't be done without making #atEnd blocking since we have to wait
for the user to flag the end of file, e.g. by typing Ctrl-D.  And #atEnd
is assumed to be non-blocking.

So currently using ZnCharacterReadStream with stdin from a terminal will
result in a stack dump similar to:

MessageNotUnderstood: receiver of "<" is nil
UndefinedObject(Object)>>doesNotUnderstand: #<
ZnUTF8Encoder>>nextCodePointFromStream:
ZnUTF8Encoder(ZnCharacterEncoder)>>nextFromStream:
ZnCharacterReadStream>>nextElement
ZnCharacterReadStream(ZnEncodedReadStream)>>next
UndefinedObject>>DoIt


Going back through the various suggestions that have been made regarding
using a sentinel object vs. raising a notification / exception, my
(still to be polished) suggestion is to:

1. Add an endOfStream instance variable
2. When the end of the stream is reached answer the value of the
   instance variable (i.e. the result of sending #value to the variable).
3. The initial default value would be a block that raises a Deprecation
   warning and then returns nil.  This would allow existing code to
   function for a changeover period.
4. At the end of the deprecation period the default value would be
   changed to a unique sentinel object which would answer itself as its
   #value.

At any time users of the stream can set their own sentinel, including a
block that raises an exception.


Cheers,
Alistair


On 4 April 2018 at 19:24, Stephane Ducasse  wrote:
> Thanks for this discussion.
>
> On Wed, Apr 4, 2018 at 1:37 PM, Sven Van Caekenberghe  wrote:
>> Alistair,
>>
>> First off, thanks for the discussions and your contributions, I really 
>> appreciate them.
>>
>> But I want to have a discussion at the high level of the definition and 
>> semantics of the stream API in Pharo.
>>
>>> On 4 Apr 2018, at 13:20, Alistair Grant  wrote:
>>>
>>> On 4 April 2018 at 12:56, Sven Van Caekenberghe  wrote:
 Playing a bit devil's advocate, the idea is that, in general,

 [ stream atEnd] whileFalse: [ stream next. "..." ].

 is no longer allowed ?
>>>
>>> It hasn't been allowed "forever" [1].  It's just been misused for
>>> almost as long.
>>>
>>> [1] Time began when stdio stream support was introduced. :-)
>>
>> I am still not convinced. Another way to put it would be that the old #atEnd 
>> or #upToEnd do not make sense for these streams and some new loop is needed, 
>> based on a new test (it exists for socket streams already).
>>
>> [ stream isDataAvailable ] whileTrue: [ stream next ]
>>
 And you want to replace it with

 [ stream next ifNil: [ false ] ifNotNil: [ :x | "..." true ] whileTrue.

 That is a pretty big change, no ?
>>>
>>> That's the way quite a bit of code already operates.
>>>
>>> As Denis pointed out, it's obviously problematic in the general sense,
>>> since nil can be embedded in non-byte oriented streams.  I suspect
>>> that in practice not many people write code that reads streams from
>>> both byte oriented and non-byte oriented streams.
>>
>> Maybe yes, maybe no. As Denis' example shows there is a clear definition 
>> problem.
>>
>> And I do use streams of byte arrays or strings all the time, this is really 
>> important. I want my parsers to work on all kinds of streams.
>>
 I think/feel like a proper EOF exception would be better, more correct.

 [ [ stream next. "..." true ] on: EOF do: [ false ] ] whileTrue.
>>>
>>> I agree, but the email thread Nicolas pointed to raises some
>>> performance questions about this approach.  It should be
>>> straightforward to do a basic performance comparison which I'll get
>>> around to if other objections aren't raised.
>>
>> Reading in bigger blocks, using #readInto:startingAt:count: (which is 
>> basically Unix's (2) Read sys call), would solve performance problems, I 
>> think.
>>
 Will we throw away #atEnd then ? Do we need it if we cannot use it ?
>>>
>>> Unix file i/o returns EOF if the end of file has been reach OR if an
>>> error occurs.  You should still check #atEnd after reading past the
>>> end of the file to make sure no error occurred.  Another part of the
>>> primitive change I'm proposing is to return additional information
>>> about what went wrong in the event of an error.
>>
>> I am sorry, but this kind of semantics (the OR) is way too complex at the 
>> general image level, it is too specific and based on certain underlying 
>> implementation details.
>>
>> Sven
>>
>>> We could modify the read primitive so that it fails if an error has
>>> occurred, and then #atEnd wouldn't be required.
>>>
>>> Cheers,
>>> Alistair
>>>
>>>

Re: [Pharo-dev] Why String do not implement #displayString?

[Denis Kudriashov]

Hi Esteban.

We have method #displayOn: but it has different purpose: argument is a kind
of canvas. So it is not related.

2018-04-10 17:28 GMT+02:00 Esteban A. Maringolo :

> Isn't #displayString implemented in terms of #displayOn: the same way
> #printString is implemented in terms of "printOn:"?
>
> And in the case of String #displayString should return the receiver (it
> is, self), so the following should be true.
>
> | s |
> s := 'Hello, ''Funny'' World'.
> s displayString = s. "true"
> s printString = s. "false"
>
> Regards,
>
>
> On 10/04/2018 12:21, Denis Kudriashov wrote:
> > Hi.
> >
> > According to the comment of #displayString it should be used as default
> > textual representation of objects in the UI:
> >
> > "While printString is about to give a detailled information about an
> > object, displayString is a message that should return a short
> > string-based representation to be used by list and related UI
> > frameworks. By default, simply return printString."
> > "asString should not be implemented in Object, and kept for
> > conversion between strings, symbols, text and characters."
> >
> > But String itself does not respect this message:
> >
> > 'some string' displayString " ==> '''someString''' "
> >
> >
> > Is it bug? Or is there any reason for this?
> >
> > Best regards,
> > Denis
>
> --
> Esteban A. Maringolo
>
>

Re: [Pharo-dev] call for help: answer on HN :)

[Sean P. DeNigris]

philippeback wrote
> Who would have envisioned the Pharo of today in the beginning?
> I am thankful for Pharo, trolls be damned.

Absolutely agree!!



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Why String do not implement #displayString?

[Esteban A. Maringolo]

Isn't #displayString implemented in terms of #displayOn: the same way
#printString is implemented in terms of "printOn:"?

And in the case of String #displayString should return the receiver (it
is, self), so the following should be true.

| s |
s := 'Hello, ''Funny'' World'.
s displayString = s. "true"
s printString = s. "false"

Regards,


On 10/04/2018 12:21, Denis Kudriashov wrote:
> Hi.
> 
> According to the comment of #displayString it should be used as default
> textual representation of objects in the UI:
> 
> "While printString is about to give a detailled information about an
> object, displayString is a message that should return a short
> string-based representation to be used by list and related UI
> frameworks. By default, simply return printString."
> "asString should not be implemented in Object, and kept for
> conversion between strings, symbols, text and characters."
> 
> But String itself does not respect this message:
> 
> 'some string' displayString " ==> '''someString''' "
> 
> 
> Is it bug? Or is there any reason for this?
> 
> Best regards,
> Denis

-- 
Esteban A. Maringolo

[Pharo-dev] Why String do not implement #displayString?

[Denis Kudriashov]

Hi.

According to the comment of #displayString it should be used as default
textual representation of objects in the UI:

"While printString is about to give a detailled information about an
object, displayString is a message that should return a short string-based
representation to be used by list and related UI frameworks. By default,
simply return printString."
"asString should not be implemented in Object, and kept for conversion
between strings, symbols, text and characters."

But String itself does not respect this message:

'some string' displayString " ==> '''someString''' "


Is it bug? Or is there any reason for this?

Best regards,
Denis

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

[Sven Van Caekenberghe]

> On 10 Apr 2018, at 16:46, Esteban A. Maringolo  wrote:
> 
> This a recurring topic in the mailing list.
> 
> See:
> http://forum.world.st/Interesting-Date-Time-Thread-on-Squeak-Dev-td4778652.html#a4778970
> 
> Or directly go to this https://www.w3.org/TR/timezone/
> 
> Pharo's Date and Time classes are incremental/offset based, whereas a
> field based Date behaves more as "expected" in terms of adding
> days/months/days/hours/etc.

That is not really true (that it depends on the internal representation).

Any date/time/datetime object needs API/behaviour that allows accessing and 
manipulation in human terms. How this is implemented is up to the 
implementation (duh).

Having separate year/month/day fields does not at all shield you from the fact 
that 'adding a day to jan 27' is different to 'adding a day to feb 27', of 'dec 
31' - the implementation has to make sure that all this works correctly (and 
this is often pretty complex, needing to take many aspects into account). 
Having separate fields suggest this is easy, but that is a delusion.

Anyway, I am pretty sure you understand.

And about Java's Calendar, I know that it is an object that manipulates other 
objects, it just has a pretty ugly interface, and does not feel very OO like. I 
hear many people curse it, but it probably does its job.

> The internal implementation might vary and there are going to be
> tradeoffs, but IMO for scheduling solutions calendar based are better
> suited.
> 
> Regards!
> 
> 
> On 10/04/2018 11:13, Stephane Ducasse wrote:
>> What is a field based date and  time?
>> 
>> On Tue, Apr 10, 2018 at 1:32 PM, Esteban A. Maringolo
>>  wrote:
>>> What is missing in the current Pharo image is a field based
>>> Date/DateTime instead of an offset+duration one as it currently is.
>>> 
>>> Why not use Chronos instead? AFAIR Chronos provides that.
>>> 
>>> An alternative would be to implement a "Calendar" (as in
>>> Java.util.Calendar [1]), that can exist in parallel with the existing
>>> Date class.
>>> 
>>> Regards,
>>> 
>>> [1] https://developer.android.com/reference/java/util/Calendar.html
>>> 
>>> On 10/04/2018 03:30, Stephane Ducasse wrote:
 Hi Paul
 
 I agree and instead of patching the current system I would start using
 TDD to design
 a new Date package.
 
 stef
 
 On Mon, Apr 9, 2018 at 8:42 PM, Paul DeBruicker  wrote:
> I  think #= is a bad selector for Date and should be avoided when 
> determining
> whether something happens on a date, or whether two dates are the same.   
> We
> all know March 24th in London covers a different 24 hours than March 24th 
> in
> Hawaii but Date>>#= does not.
> 
> 
> 
> I think whats needed are more descriptive selectors like
> 
> 
> Date>>#isSameOnDateAs: aDateOrDateAndTime
> Date>>#overlapsWithDate: aDate
> DateAndTime>>#occursOnDate: aDate
> DateAndTime>>#sameHMSButDifferentUTCIn: aTimeZoneKey
> DateAndTime>>#sameUTCButDifferentHMSIn: aTimeZoneKey
> 
> and change Date>>#= to #shouldNotImplement.
> 
> 
> FWIW I also don't like #offset: as before you send it you know the 
> timezone
> and after you may let that knowledge be forgotten. Real offsets can change
> as laws change.
> 
> 
> 
> I think people are aware of this but if you have need for comparing dates 
> &
> times then you must use a library that accesses the regularly updated 
> Olson
> timezone database on your system and classes that respect time zones.  
> Time
> zones are political, and legal definitions of offsets can change hours
> before the DST transition dates & times.
> 
> 
> I don't think it matters which default timezone you pick for the image if
> you're not going to take them into account when doing comparisons.
> 
> 
> Unfortunately there isn't a way to avoid this complexity until DST goes
> away.
> 
> 
> There's certainly flaws to how we currently do it and I think
> TimeZoneDatabase and Chronos make good attempts to fix it.  I haven't 
> looked
> at Chalten but would guess its good too.
> 
> 
> 
> 
> 
> 
> 
> 
> Sean P. DeNigris wrote
>> I was bitten by this very annoying bug again. As most of us probably know
>> due
>> to the steady stream of confused ML posts in the past, the bug in summary
>> is
>> that we have an incomplete timezone implementation that doesn't properly
>> take into account historical DST changes. This flares up without warning
>> especially when DST toggles. I created a wiki page to document the
>> situation: https://github.com/seandenigris/pharo/wiki/Time-Zone-Fiasco
>> 
>> Here's an example blowup: at 11:59pm before DST changes, eval aDate :=
>> '1/1/1901' asDate. Now, wait two minutes and at 12:01am eval 

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

[Esteban A. Maringolo]

On 10/04/2018 11:37, Sven Van Caekenberghe wrote:

> Right now, we are discussing what should be in the image by default.
> 
> The current system is not bad at all, it just has deficiencies that could be 
> improved upon.
> 
>> An alternative would be to implement a "Calendar" (as in
>> Java.util.Calendar [1]), that can exist in parallel with the existing
>> Date class.
> 
> I am not so sure that is a good example. 

First time I new about Calendar I found it awkward (starting with the
name). Years later I understood its purpose in comparison with a "point
in time" Date or Timestamp.

The name and implementation are TBD, but what I'm trying to exemplify is
a particular case in a popular language.

Regards!

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

[Esteban A. Maringolo]

This a recurring topic in the mailing list.

See:
http://forum.world.st/Interesting-Date-Time-Thread-on-Squeak-Dev-td4778652.html#a4778970

Or directly go to this https://www.w3.org/TR/timezone/

Pharo's Date and Time classes are incremental/offset based, whereas a
field based Date behaves more as "expected" in terms of adding
days/months/days/hours/etc.

The internal implementation might vary and there are going to be
tradeoffs, but IMO for scheduling solutions calendar based are better
suited.

Regards!


On 10/04/2018 11:13, Stephane Ducasse wrote:
> What is a field based date and  time?
>
> On Tue, Apr 10, 2018 at 1:32 PM, Esteban A. Maringolo
>  wrote:
>> What is missing in the current Pharo image is a field based
>> Date/DateTime instead of an offset+duration one as it currently is.
>>
>> Why not use Chronos instead? AFAIR Chronos provides that.
>>
>> An alternative would be to implement a "Calendar" (as in
>> Java.util.Calendar [1]), that can exist in parallel with the existing
>> Date class.
>>
>> Regards,
>>
>> [1] https://developer.android.com/reference/java/util/Calendar.html
>>
>> On 10/04/2018 03:30, Stephane Ducasse wrote:
>>> Hi Paul
>>>
>>> I agree and instead of patching the current system I would start using
>>> TDD to design
>>> a new Date package.
>>>
>>> stef
>>>
>>> On Mon, Apr 9, 2018 at 8:42 PM, Paul DeBruicker  wrote:
 I  think #= is a bad selector for Date and should be avoided when 
 determining
 whether something happens on a date, or whether two dates are the same.   
 We
 all know March 24th in London covers a different 24 hours than March 24th 
 in
 Hawaii but Date>>#= does not.



 I think whats needed are more descriptive selectors like


 Date>>#isSameOnDateAs: aDateOrDateAndTime
 Date>>#overlapsWithDate: aDate
 DateAndTime>>#occursOnDate: aDate
 DateAndTime>>#sameHMSButDifferentUTCIn: aTimeZoneKey
 DateAndTime>>#sameUTCButDifferentHMSIn: aTimeZoneKey

 and change Date>>#= to #shouldNotImplement.


 FWIW I also don't like #offset: as before you send it you know the timezone
 and after you may let that knowledge be forgotten. Real offsets can change
 as laws change.



 I think people are aware of this but if you have need for comparing dates &
 times then you must use a library that accesses the regularly updated Olson
 timezone database on your system and classes that respect time zones.  Time
 zones are political, and legal definitions of offsets can change hours
 before the DST transition dates & times.


 I don't think it matters which default timezone you pick for the image if
 you're not going to take them into account when doing comparisons.


 Unfortunately there isn't a way to avoid this complexity until DST goes
 away.


 There's certainly flaws to how we currently do it and I think
 TimeZoneDatabase and Chronos make good attempts to fix it.  I haven't 
 looked
 at Chalten but would guess its good too.








 Sean P. DeNigris wrote
> I was bitten by this very annoying bug again. As most of us probably know
> due
> to the steady stream of confused ML posts in the past, the bug in summary
> is
> that we have an incomplete timezone implementation that doesn't properly
> take into account historical DST changes. This flares up without warning
> especially when DST toggles. I created a wiki page to document the
> situation: https://github.com/seandenigris/pharo/wiki/Time-Zone-Fiasco
>
> Here's an example blowup: at 11:59pm before DST changes, eval aDate :=
> '1/1/1901' asDate. Now, wait two minutes and at 12:01am eval self assert:
> '1/1/1901' asDate = aDate and… whammo, an exception! The "different"
> offsets
> render equal dates unequal depending on when the objects were created.
>
> The more I think about it, the more I think that we should just assume UTC
> for all Date[AndTime]s that don't explicitly specify an offset, rather
> than
> pretend to set an offset which is only sometimes correct. More advanced
> users can use one of the available libraries to get full timezone support.
> What do you think?
>
>
>
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html




 --
 Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

>> --
>> Esteban A. Maringolo
>>

-- 
Esteban A. Maringolo

Re: [Pharo-dev] [TechTalk] April 12: GIT with Iceberg

[Esteban Lorenzano]

more like to present the new UI (it received a complete revamp, so we need to 
inform about it ;) )

cheers!
Esteban

> On 10 Apr 2018, at 16:34, Marcus Denker  wrote:
> 
> Hi,
> 
> There next TechTalk will be April 12: GIT with Iceberg
> 
>   https://association.pharo.org/event-2797068
> 
> 
> A regular chat about Pharo. Happens on Discord.
> 
> The Tech talks are open to both members and non-members! 
> 
> Topic:  GIT with Iceberg. Demo of improved UI
> 
> We will send an information to all subscribers some hours before the talk 
> starts.
> 
> 
> 

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

[Sven Van Caekenberghe]

> On 10 Apr 2018, at 13:32, Esteban A. Maringolo  wrote:
> 
> 
> What is missing in the current Pharo image is a field based
> Date/DateTime instead of an offset+duration one as it currently is.
> 
> Why not use Chronos instead? AFAIR Chronos provides that.

Like Sean said elsewhere, the exist (much) better add-on frameworks, if you 
choose to use them, but they are optional.

Right now, we are discussing what should be in the image by default.

The current system is not bad at all, it just has deficiencies that could be 
improved upon.

> An alternative would be to implement a "Calendar" (as in
> Java.util.Calendar [1]), that can exist in parallel with the existing
> Date class.

I am not so sure that is a good example. 

> Regards,
> 
> [1] https://developer.android.com/reference/java/util/Calendar.html
> 
> On 10/04/2018 03:30, Stephane Ducasse wrote:
>> Hi Paul
>> 
>> I agree and instead of patching the current system I would start using
>> TDD to design
>> a new Date package.
>> 
>> stef
>> 
>> On Mon, Apr 9, 2018 at 8:42 PM, Paul DeBruicker  wrote:
>>> I  think #= is a bad selector for Date and should be avoided when 
>>> determining
>>> whether something happens on a date, or whether two dates are the same.   We
>>> all know March 24th in London covers a different 24 hours than March 24th in
>>> Hawaii but Date>>#= does not.
>>> 
>>> 
>>> 
>>> I think whats needed are more descriptive selectors like
>>> 
>>> 
>>> Date>>#isSameOnDateAs: aDateOrDateAndTime
>>> Date>>#overlapsWithDate: aDate
>>> DateAndTime>>#occursOnDate: aDate
>>> DateAndTime>>#sameHMSButDifferentUTCIn: aTimeZoneKey
>>> DateAndTime>>#sameUTCButDifferentHMSIn: aTimeZoneKey
>>> 
>>> and change Date>>#= to #shouldNotImplement.
>>> 
>>> 
>>> FWIW I also don't like #offset: as before you send it you know the timezone
>>> and after you may let that knowledge be forgotten. Real offsets can change
>>> as laws change.
>>> 
>>> 
>>> 
>>> I think people are aware of this but if you have need for comparing dates &
>>> times then you must use a library that accesses the regularly updated Olson
>>> timezone database on your system and classes that respect time zones.  Time
>>> zones are political, and legal definitions of offsets can change hours
>>> before the DST transition dates & times.
>>> 
>>> 
>>> I don't think it matters which default timezone you pick for the image if
>>> you're not going to take them into account when doing comparisons.
>>> 
>>> 
>>> Unfortunately there isn't a way to avoid this complexity until DST goes
>>> away.
>>> 
>>> 
>>> There's certainly flaws to how we currently do it and I think
>>> TimeZoneDatabase and Chronos make good attempts to fix it.  I haven't looked
>>> at Chalten but would guess its good too.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Sean P. DeNigris wrote
 I was bitten by this very annoying bug again. As most of us probably know
 due
 to the steady stream of confused ML posts in the past, the bug in summary
 is
 that we have an incomplete timezone implementation that doesn't properly
 take into account historical DST changes. This flares up without warning
 especially when DST toggles. I created a wiki page to document the
 situation: https://github.com/seandenigris/pharo/wiki/Time-Zone-Fiasco
 
 Here's an example blowup: at 11:59pm before DST changes, eval aDate :=
 '1/1/1901' asDate. Now, wait two minutes and at 12:01am eval self assert:
 '1/1/1901' asDate = aDate and… whammo, an exception! The "different"
 offsets
 render equal dates unequal depending on when the objects were created.
 
 The more I think about it, the more I think that we should just assume UTC
 for all Date[AndTime]s that don't explicitly specify an offset, rather
 than
 pretend to set an offset which is only sometimes correct. More advanced
 users can use one of the available libraries to get full timezone support.
 What do you think?
 
 
 
 -
 Cheers,
 Sean
 --
 Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>>> 
>>> 
>>> 
>>> 
>>> 
>>> --
>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>>> 
>> 
> 
> -- 
> Esteban A. Maringolo
> 

[Pharo-dev] [TechTalk] April 12: GIT with Iceberg

[Marcus Denker]

Hi,

There next TechTalk will be April 12: GIT with Iceberg

https://association.pharo.org/event-2797068


A regular chat about Pharo. Happens on Discord.

The Tech talks are open to both members and non-members! 

Topic:  GIT with Iceberg. Demo of improved UI

We will send an information to all subscribers some hours before the talk 
starts.

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

[Sven Van Caekenberghe]

> On 10 Apr 2018, at 16:13, Stephane Ducasse  wrote:
> 
> What is a field based date and  time?

This is more of an implementation choice but it has probably influence on the 
API as well.

Field based date/time/datetime objects are like the naive implementation where 
each element that we talk about as humans has its own instance variable. You 
would store hours, minutes, seconds, nanosecond separately, as well as year, 
month, day.

This is not as efficient as the current implementations, where time is 
typically stored as seconds and nanoseconds, and dates as a single julian day 
number.

Still, these are implementation choices. For example, the split between seconds 
and nanoseconds is a bit artificial as well (it is so that both remain 
SmallIntegers in 32-bit), while in 64-bit this decision could be revised.

> On Tue, Apr 10, 2018 at 1:32 PM, Esteban A. Maringolo
>  wrote:
>> 
>> What is missing in the current Pharo image is a field based
>> Date/DateTime instead of an offset+duration one as it currently is.
>> 
>> Why not use Chronos instead? AFAIR Chronos provides that.
>> 
>> An alternative would be to implement a "Calendar" (as in
>> Java.util.Calendar [1]), that can exist in parallel with the existing
>> Date class.
>> 
>> Regards,
>> 
>> [1] https://developer.android.com/reference/java/util/Calendar.html
>> 
>> On 10/04/2018 03:30, Stephane Ducasse wrote:
>>> Hi Paul
>>> 
>>> I agree and instead of patching the current system I would start using
>>> TDD to design
>>> a new Date package.
>>> 
>>> stef
>>> 
>>> On Mon, Apr 9, 2018 at 8:42 PM, Paul DeBruicker  wrote:
 I  think #= is a bad selector for Date and should be avoided when 
 determining
 whether something happens on a date, or whether two dates are the same.   
 We
 all know March 24th in London covers a different 24 hours than March 24th 
 in
 Hawaii but Date>>#= does not.
 
 
 
 I think whats needed are more descriptive selectors like
 
 
 Date>>#isSameOnDateAs: aDateOrDateAndTime
 Date>>#overlapsWithDate: aDate
 DateAndTime>>#occursOnDate: aDate
 DateAndTime>>#sameHMSButDifferentUTCIn: aTimeZoneKey
 DateAndTime>>#sameUTCButDifferentHMSIn: aTimeZoneKey
 
 and change Date>>#= to #shouldNotImplement.
 
 
 FWIW I also don't like #offset: as before you send it you know the timezone
 and after you may let that knowledge be forgotten. Real offsets can change
 as laws change.
 
 
 
 I think people are aware of this but if you have need for comparing dates &
 times then you must use a library that accesses the regularly updated Olson
 timezone database on your system and classes that respect time zones.  Time
 zones are political, and legal definitions of offsets can change hours
 before the DST transition dates & times.
 
 
 I don't think it matters which default timezone you pick for the image if
 you're not going to take them into account when doing comparisons.
 
 
 Unfortunately there isn't a way to avoid this complexity until DST goes
 away.
 
 
 There's certainly flaws to how we currently do it and I think
 TimeZoneDatabase and Chronos make good attempts to fix it.  I haven't 
 looked
 at Chalten but would guess its good too.
 
 
 
 
 
 
 
 
 Sean P. DeNigris wrote
> I was bitten by this very annoying bug again. As most of us probably know
> due
> to the steady stream of confused ML posts in the past, the bug in summary
> is
> that we have an incomplete timezone implementation that doesn't properly
> take into account historical DST changes. This flares up without warning
> especially when DST toggles. I created a wiki page to document the
> situation: https://github.com/seandenigris/pharo/wiki/Time-Zone-Fiasco
> 
> Here's an example blowup: at 11:59pm before DST changes, eval aDate :=
> '1/1/1901' asDate. Now, wait two minutes and at 12:01am eval self assert:
> '1/1/1901' asDate = aDate and… whammo, an exception! The "different"
> offsets
> render equal dates unequal depending on when the objects were created.
> 
> The more I think about it, the more I think that we should just assume UTC
> for all Date[AndTime]s that don't explicitly specify an offset, rather
> than
> pretend to set an offset which is only sometimes correct. More advanced
> users can use one of the available libraries to get full timezone support.
> What do you think?
> 
> 
> 
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
 
 
 
 
 
 --
 Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
 
>>> 
>> 
>> --
>> Esteban A. Maringolo
>> 
> 

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

[Stephane Ducasse]

What is a field based date and  time?

On Tue, Apr 10, 2018 at 1:32 PM, Esteban A. Maringolo
 wrote:
>
> What is missing in the current Pharo image is a field based
> Date/DateTime instead of an offset+duration one as it currently is.
>
> Why not use Chronos instead? AFAIR Chronos provides that.
>
> An alternative would be to implement a "Calendar" (as in
> Java.util.Calendar [1]), that can exist in parallel with the existing
> Date class.
>
> Regards,
>
> [1] https://developer.android.com/reference/java/util/Calendar.html
>
> On 10/04/2018 03:30, Stephane Ducasse wrote:
>> Hi Paul
>>
>> I agree and instead of patching the current system I would start using
>> TDD to design
>> a new Date package.
>>
>> stef
>>
>> On Mon, Apr 9, 2018 at 8:42 PM, Paul DeBruicker  wrote:
>>> I  think #= is a bad selector for Date and should be avoided when 
>>> determining
>>> whether something happens on a date, or whether two dates are the same.   We
>>> all know March 24th in London covers a different 24 hours than March 24th in
>>> Hawaii but Date>>#= does not.
>>>
>>>
>>>
>>> I think whats needed are more descriptive selectors like
>>>
>>>
>>> Date>>#isSameOnDateAs: aDateOrDateAndTime
>>> Date>>#overlapsWithDate: aDate
>>> DateAndTime>>#occursOnDate: aDate
>>> DateAndTime>>#sameHMSButDifferentUTCIn: aTimeZoneKey
>>> DateAndTime>>#sameUTCButDifferentHMSIn: aTimeZoneKey
>>>
>>> and change Date>>#= to #shouldNotImplement.
>>>
>>>
>>> FWIW I also don't like #offset: as before you send it you know the timezone
>>> and after you may let that knowledge be forgotten. Real offsets can change
>>> as laws change.
>>>
>>>
>>>
>>> I think people are aware of this but if you have need for comparing dates &
>>> times then you must use a library that accesses the regularly updated Olson
>>> timezone database on your system and classes that respect time zones.  Time
>>> zones are political, and legal definitions of offsets can change hours
>>> before the DST transition dates & times.
>>>
>>>
>>> I don't think it matters which default timezone you pick for the image if
>>> you're not going to take them into account when doing comparisons.
>>>
>>>
>>> Unfortunately there isn't a way to avoid this complexity until DST goes
>>> away.
>>>
>>>
>>> There's certainly flaws to how we currently do it and I think
>>> TimeZoneDatabase and Chronos make good attempts to fix it.  I haven't looked
>>> at Chalten but would guess its good too.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Sean P. DeNigris wrote
 I was bitten by this very annoying bug again. As most of us probably know
 due
 to the steady stream of confused ML posts in the past, the bug in summary
 is
 that we have an incomplete timezone implementation that doesn't properly
 take into account historical DST changes. This flares up without warning
 especially when DST toggles. I created a wiki page to document the
 situation: https://github.com/seandenigris/pharo/wiki/Time-Zone-Fiasco

 Here's an example blowup: at 11:59pm before DST changes, eval aDate :=
 '1/1/1901' asDate. Now, wait two minutes and at 12:01am eval self assert:
 '1/1/1901' asDate = aDate and… whammo, an exception! The "different"
 offsets
 render equal dates unequal depending on when the objects were created.

 The more I think about it, the more I think that we should just assume UTC
 for all Date[AndTime]s that don't explicitly specify an offset, rather
 than
 pretend to set an offset which is only sometimes correct. More advanced
 users can use one of the available libraries to get full timezone support.
 What do you think?



 -
 Cheers,
 Sean
 --
 Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>>>
>>
>
> --
> Esteban A. Maringolo
>

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

[Esteban A. Maringolo]

What is missing in the current Pharo image is a field based
Date/DateTime instead of an offset+duration one as it currently is.

Why not use Chronos instead? AFAIR Chronos provides that.

An alternative would be to implement a "Calendar" (as in
Java.util.Calendar [1]), that can exist in parallel with the existing
Date class.

Regards,

[1] https://developer.android.com/reference/java/util/Calendar.html

On 10/04/2018 03:30, Stephane Ducasse wrote:
> Hi Paul
> 
> I agree and instead of patching the current system I would start using
> TDD to design
> a new Date package.
> 
> stef
> 
> On Mon, Apr 9, 2018 at 8:42 PM, Paul DeBruicker  wrote:
>> I  think #= is a bad selector for Date and should be avoided when determining
>> whether something happens on a date, or whether two dates are the same.   We
>> all know March 24th in London covers a different 24 hours than March 24th in
>> Hawaii but Date>>#= does not.
>>
>>
>>
>> I think whats needed are more descriptive selectors like
>>
>>
>> Date>>#isSameOnDateAs: aDateOrDateAndTime
>> Date>>#overlapsWithDate: aDate
>> DateAndTime>>#occursOnDate: aDate
>> DateAndTime>>#sameHMSButDifferentUTCIn: aTimeZoneKey
>> DateAndTime>>#sameUTCButDifferentHMSIn: aTimeZoneKey
>>
>> and change Date>>#= to #shouldNotImplement.
>>
>>
>> FWIW I also don't like #offset: as before you send it you know the timezone
>> and after you may let that knowledge be forgotten. Real offsets can change
>> as laws change.
>>
>>
>>
>> I think people are aware of this but if you have need for comparing dates &
>> times then you must use a library that accesses the regularly updated Olson
>> timezone database on your system and classes that respect time zones.  Time
>> zones are political, and legal definitions of offsets can change hours
>> before the DST transition dates & times.
>>
>>
>> I don't think it matters which default timezone you pick for the image if
>> you're not going to take them into account when doing comparisons.
>>
>>
>> Unfortunately there isn't a way to avoid this complexity until DST goes
>> away.
>>
>>
>> There's certainly flaws to how we currently do it and I think
>> TimeZoneDatabase and Chronos make good attempts to fix it.  I haven't looked
>> at Chalten but would guess its good too.
>>
>>
>>
>>
>>
>>
>>
>>
>> Sean P. DeNigris wrote
>>> I was bitten by this very annoying bug again. As most of us probably know
>>> due
>>> to the steady stream of confused ML posts in the past, the bug in summary
>>> is
>>> that we have an incomplete timezone implementation that doesn't properly
>>> take into account historical DST changes. This flares up without warning
>>> especially when DST toggles. I created a wiki page to document the
>>> situation: https://github.com/seandenigris/pharo/wiki/Time-Zone-Fiasco
>>>
>>> Here's an example blowup: at 11:59pm before DST changes, eval aDate :=
>>> '1/1/1901' asDate. Now, wait two minutes and at 12:01am eval self assert:
>>> '1/1/1901' asDate = aDate and… whammo, an exception! The "different"
>>> offsets
>>> render equal dates unequal depending on when the objects were created.
>>>
>>> The more I think about it, the more I think that we should just assume UTC
>>> for all Date[AndTime]s that don't explicitly specify an offset, rather
>>> than
>>> pretend to set an offset which is only sometimes correct. More advanced
>>> users can use one of the available libraries to get full timezone support.
>>> What do you think?
>>>
>>>
>>>
>>> -
>>> Cheers,
>>> Sean
>>> --
>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>>
>>
>>
>>
>>
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>>
> 

-- 
Esteban A. Maringolo

[Pharo-dev] [Pharo 7.0-dev] Build #759: 21680-haltIfTest-and-haltIfNotTest-and-comments

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #759 was: SUCCESS.

The Pull Request #1187 was integrated: 
"21680-haltIfTest-and-haltIfNotTest-and-comments"
Pull request url: https://github.com/pharo-project/pharo/pull/1187

Issue Url: https://pharo.fogbugz.com/f/cases/21680
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/759/

Re: [Pharo-dev] [Pharo7] halt inside and outside tests

[Marcus Denker]

> On 5 Apr 2018, at 09:10, Marcus Denker  wrote:
> 
> 
> 
>> On 3 Apr 2018, at 21:56, Christophe Demarey > > wrote:
>> 
>> Nice addition!
>> I should say that names are not really intention revealing.
>> What about haltIfTestExecutionEnvironment and 
>> haltIfDefaultExecutionEnvironment ?
>> 
> To long and too implementation centered. 
> 
> I would even shorten it to haltIfTest and haltIfNotTest.
> 

https://github.com/pharo-project/pharo/pull/1187/files 


I simplified them further and added test (will be in the next build)

Marcus

Re: [Pharo-dev] call for help: answer on HN :)

[p...@highoctane.be]

On Tue, Apr 10, 2018, 08:17 Stephane Ducasse 
wrote:

> It was a year ago and now Iceberg will become iceberg20.
> And a year ago we could/should have used Pharo 50 but we used Pharo
> 6.1 and the 64bits bit us.
> Let us focus on the future and yes we should improve.
>

If there is something I learned from the Pharo community, this is this
persistent will to make it movd forward and become better.

There have been failed experiments along the way but mostly a lot of
positive things.

Who would have envisioned the Pharo of today in the beginning?

Despite criticism, people are trucking forward. That's great and definitely
inspiring.

I am thankful for Pharo, trolls be damned.

Phil

>
> Stef
>
> On Tue, Apr 10, 2018 at 3:32 AM, Sean P. DeNigris 
> wrote:
> > Stephane Ducasse-3 wrote
> >> I told them NOT to use github.
> >> I told them that Bloc was alpha.
> >
> > I wonder if we could make those points more explicit. Maybe a welcome
> window
> > disclaimer for Iceberg, since it's preinstalled?
> >
> >
> >
> > -
> > Cheers,
> > Sean
> > --
> > Sent from:
> http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
> >
>
>

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

[Jaroslaw Podgajny]

It has always been my intuition that Date (and Time) model has to contain
the time zone the Date is supposed to represent, e.g. like in
y/m/d+timezone. This way we would always have an object that precisely
represents an absolute point in time. Very many problems, if not all,
discussed here only arise when two instances of time magnitude are being
compared. This seems to me much better addressed if taken into
consideration at the time of comparison.
Some conventions would have to be introduced to create deterministic
response for arithmetics but at least the exposure to the complex semantics
and computational overhead go away until it cannot any longer be avoided:
when ultimate point in time has to be converted in line with the current
legal stance of the definitions. This also hints towards the requirement
for having a “time of arithmetic operation” play a role in the comparison
in order to allow programmatic reasoning about date/time arithmetics as
taken in the past, e.g. before a particular regulation adjusted particular
semantics.
In practical terms comparing a Date expressed in EST with a date expressed
in Zulu could be resolved by first coercing the units both instances are
expressed in, say to UTC, and then performing arithmetics.
Such view also resonates with Sean’s observation below that offset of 0
seems reasonable...



Regards, Jaroslaw


On Mon, 9 Apr 2018 at 17:53, Sean P. DeNigris  wrote:

> Sven Van Caekenberghe-2 wrote
> > I think that making Date always UTC will probably not help, because you
> > will want to be able to move between timezones
>
> Two things:
> - I don't think changing timezones will be affected, because my proposal is
> only: "default to 0 offset for new Date[AndTime] instances where no offset
> is specified". This would not prevent changing the offset later on
> (although
> one would make the case that since guessing default offset is unfixable in
> practice in the core, it should be removed altogether), and it also
> wouldn't
> affect the offset of the image, so `Date today` would still use the local
> offset.
> - I'm not saying that it is a panacea, but it will avoid the bug in
> question. It is less wrong than the current behavior and will allow those
> of
> us on DST to keep our sanity while we come up with a more perfect long term
> solution.
>
> What is the downside to this change?
>
>
>
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>
>

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

[Stephane Ducasse]

Hi Paul

I agree and instead of patching the current system I would start using
TDD to design
a new Date package.

stef

On Mon, Apr 9, 2018 at 8:42 PM, Paul DeBruicker  wrote:
> I  think #= is a bad selector for Date and should be avoided when determining
> whether something happens on a date, or whether two dates are the same.   We
> all know March 24th in London covers a different 24 hours than March 24th in
> Hawaii but Date>>#= does not.
>
>
>
> I think whats needed are more descriptive selectors like
>
>
> Date>>#isSameOnDateAs: aDateOrDateAndTime
> Date>>#overlapsWithDate: aDate
> DateAndTime>>#occursOnDate: aDate
> DateAndTime>>#sameHMSButDifferentUTCIn: aTimeZoneKey
> DateAndTime>>#sameUTCButDifferentHMSIn: aTimeZoneKey
>
> and change Date>>#= to #shouldNotImplement.
>
>
> FWIW I also don't like #offset: as before you send it you know the timezone
> and after you may let that knowledge be forgotten. Real offsets can change
> as laws change.
>
>
>
> I think people are aware of this but if you have need for comparing dates &
> times then you must use a library that accesses the regularly updated Olson
> timezone database on your system and classes that respect time zones.  Time
> zones are political, and legal definitions of offsets can change hours
> before the DST transition dates & times.
>
>
> I don't think it matters which default timezone you pick for the image if
> you're not going to take them into account when doing comparisons.
>
>
> Unfortunately there isn't a way to avoid this complexity until DST goes
> away.
>
>
> There's certainly flaws to how we currently do it and I think
> TimeZoneDatabase and Chronos make good attempts to fix it.  I haven't looked
> at Chalten but would guess its good too.
>
>
>
>
>
>
>
>
> Sean P. DeNigris wrote
>> I was bitten by this very annoying bug again. As most of us probably know
>> due
>> to the steady stream of confused ML posts in the past, the bug in summary
>> is
>> that we have an incomplete timezone implementation that doesn't properly
>> take into account historical DST changes. This flares up without warning
>> especially when DST toggles. I created a wiki page to document the
>> situation: https://github.com/seandenigris/pharo/wiki/Time-Zone-Fiasco
>>
>> Here's an example blowup: at 11:59pm before DST changes, eval aDate :=
>> '1/1/1901' asDate. Now, wait two minutes and at 12:01am eval self assert:
>> '1/1/1901' asDate = aDate and… whammo, an exception! The "different"
>> offsets
>> render equal dates unequal depending on when the objects were created.
>>
>> The more I think about it, the more I think that we should just assume UTC
>> for all Date[AndTime]s that don't explicitly specify an offset, rather
>> than
>> pretend to set an offset which is only sometimes correct. More advanced
>> users can use one of the available libraries to get full timezone support.
>> What do you think?
>>
>>
>>
>> -
>> Cheers,
>> Sean
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>
>
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

[Stephane Ducasse]

Hi Sven

I'm totally stupid on this topic now I was retrospectively thinking
about the situation
already some years ago.
We tried to enhance the old core back when we were still in Squeak and now
I would do the opposite.

I would make sure that the core is only working for the pharo logic
(and use the minimal set of abstractions
covering only the minimum for pharo core) and provide a good library
for other cases.

What you think?

Alternatively we could have Date -> SimpleDate
and add ZTimezone.

Last time I played with Date and Span I got confused (It was for
automatically issuing bills each month) and I realised that
the abstractions we have are clunky or may be I did not use them. I
wanted to have a month in a year (for example to get
the 29 or 28 automatically and I had to do all kind of tricks.

Stef





On Mon, Apr 9, 2018 at 5:26 PM, Sven Van Caekenberghe  wrote:
>
>
>> On 9 Apr 2018, at 15:19, Sean P. DeNigris  wrote:
>>
>> Max Leske wrote
>>> Assuming UTC is probably just as wrong as assuming the local time zone.
>>
>> I'll modify your statement slightly. "Assuming UTC is */almost/* as wrong as
>> assuming the local time zone."
>>
>> I've never seemed to be able to drive the essential point home when these
>> discussions have come up. Beyond all the wider issues, there is a bug, plain
>> and simple: The offset of `'1/1/1990' asDate`, considering that you mean
>> local time, is still not guaranteed to be the current local offset of the
>> image, which is how we set it by default. That only makes sense if the
>> historical date in question was in the same state of DST as the current
>> image. For example, the historical date above is in winter, so if I eval
>> that code in summer, it will /always/ give the objectively wrong offset.
>>
>> What I'm proposing is not a cure all, but a slightly-better way that fixes
>> this bug by giving users consistent behavior that they may not want instead
>> of inconsistent and often wrong behavior that they may not want.
>
> Sean,
>
> You are right, the current system cannot be fixed. It only knows about the 
> current timezone's offset (via the OS), not about historical offsets. And it 
> wrongly uses that offset because it does not know better.
>
> Neither
>
>   '1/1/1990' asDate.
>
> nor
>
>   Date today.
>
> can work without the context of a precise timezone. It is even relatively 
> pointless to remember offsets without remembering timezones. You simply need 
> a precise reference into the transitions database.
>
> New York is 5 hours behind UTC in winter.
>
> Question 1: When (in absolute UTC time) was the beginning of the 1st day of 
> January in 1990 in New York's local time, when we express the date in UTC ?
>
> (ZTimezone id: 'America/New_York') gmtToLocal: (ZTimestamp @ '1990/01/01').
>
>   => "1989-12-31T19:00:00Z"
>
> So when the UTC day of January 1st 1990 starts, New York local time is still 
> 5 hours behind.
>
> Question 2: When (in absolute UTC time) was the beginning of the 1st day of 
> January in 1990 in UTC time, when we express the date locally ?
>
> (ZTimezone id: 'America/New_York') localToGmt: (ZTimestamp @ '1990/01/01').
>
>   => "1990-01-01T05:00:00Z"
>
> So when the New York day of January 1st 1990 starts, UTC time is already 5 
> hours ahead.
>
> Note that the question 'When does January 1st 1990 start in any timezone, 
> when expressed in that timezone, is of course a constant, midnight'.
>
>
> I think that making Date always UTC will probably not help, because you will 
> want to be able to move between timezones. I guess the only solution is to 
> add a class like ZTimezone (which has no dependencies).
>
>
> Sven
>
>> -
>> Cheers,
>> Sean
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>>
>
>

Re: [Pharo-dev] call for help: answer on HN :)

[Stephane Ducasse]

It was a year ago and now Iceberg will become iceberg20.
And a year ago we could/should have used Pharo 50 but we used Pharo
6.1 and the 64bits bit us.
Let us focus on the future and yes we should improve.

Stef

On Tue, Apr 10, 2018 at 3:32 AM, Sean P. DeNigris  wrote:
> Stephane Ducasse-3 wrote
>> I told them NOT to use github.
>> I told them that Bloc was alpha.
>
> I wonder if we could make those points more explicit. Maybe a welcome window
> disclaimer for Iceberg, since it's preinstalled?
>
>
>
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>