Re: [Pharo-dev] Executive Programming

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 *

Re: [Pharo-dev] Executive Programming

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

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

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"

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

--- 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:

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

--- 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!

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

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

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

> 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

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

--- 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? -

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

--- 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

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

> 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,

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

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

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

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

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

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

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

> 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

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

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

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

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

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

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,

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

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

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

> 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

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

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

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

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

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

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.

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

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

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

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

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

> 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

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

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/ >

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

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 ...

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

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

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

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

[Pharo-dev] Contribute a Fix and Reviewing changes

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

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

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

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

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

Re: [Pharo-dev] Executive Programming

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

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

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

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

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

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

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

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

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

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

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?

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.

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

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

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

> 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/ > >

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

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 >>

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

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

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

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 > >

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

> 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

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

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

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

> 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

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

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

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

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

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

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:

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

> 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. >>

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

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

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

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

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

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

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

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

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

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: >