Re: [Pharo-dev] Laucher cannot start a fresh 7 image

[Esteban A. Maringolo]

I reported this a week or so ago, same issue.

On 11/10/2018 03:09, p...@highoctane.be wrote:
> Used to work. Then does not anymore.
> 
> Phil

-- 
Esteban A. Maringolo

Re: [Pharo-dev] Pharo Downloads are sluggish

[Esteban A. Maringolo]

Hi Marcus,

Thank you and all the team for this.

Best regards,

--
Esteban A. Maringolo

On 24/09/2018 07:05, Marcus Denker wrote:
> Hello,
> 
> We are switching the hosting contract to a more professional one. This
> should be active soon.
> 
> This includes a CDN, but it will be active only after we make sure that
> the files get invalidated when the
> CI uploads them, so this will be in a week or so.
> 
> It should improve things even without the CDN active, though.
> 
> Marcus

Re: [Pharo-dev] Pharo Downloads are sluggish

[Esteban A. Maringolo]

On 20/09/2018 02:11, ponyatov wrote:
> Just add Torrent as download variant

Torrent for a 50mb/file is overkill today.
And adds a new requirement to get started.

A Torrent based Pharo launcher is a different story :)

Regards,

-- 
Esteban A. Maringolo

Re: [Pharo-dev] Pharo Downloads are sluggish

[Esteban A. Maringolo]

Hi Marcus,

Thank you.

Anybody WILLING to use it will wait whatever it takes, but my concern,
and rant, is about these that want to give it a try and will abort it
even before running it.

I'm happily using Pharo in Windows preparing it for a demo I'll be making.


Regards!

On 19/09/2018 10:06, Marcus Denker wrote:
> I will have a look how to improve the situation.
> 
> (I hope to be able to do it by next week).
> 
> Marcus
> 
>> On 19 Sep 2018, at 02:10, Esteban Maringolo > <mailto:emaring...@gmail.com>> wrote:
>>
>> After sending the previous email I checked the progress and it was
>> aborted due to a network error.
>>
>> 
>>
>> I retried and apparently the speed got to a more reasonable one, with
>> peaks of 300KB/sec.
>>
>> 
>>
>>
>> My guess is that the bottleneck is at where the files are hosted, and
>> if you attempt to download while maybe there are several CI builds
>> running or something else is using the fileserver bandwidth, then it
>> impacts the overall download speed of those attempting to download
>> just the basic elements.
>>
>> Regards!
>>
>> Esteban A. Maringolo
>>
>>
>> El mar., 18 sept. 2018 a las 21:03, Esteban Maringolo
>> (mailto:emaring...@gmail.com>>) escribió:
>>
>> Is there a reason why the latest version of the builds linked from
>> the website are not hosted in some CDN, Amazon S3 or similar?
>>
>> Maybe in Europe the speed is fast, but where I am (Argentina) it
>> is really slow, the screenshot shows 3.5KB/s, it averages 10KB/s,
>> with peaks of 40KB/s.
>>
>> This is an pitiful boarding experience, that will make many cancel
>>     it even before getting to open the downloaded launcher.
>>
>> 
>>
>> The screenshot shows that is not a problem with my home
>> connection, which isn't the fastest but is "normal" for my use cases.
>>
>> Regards,
>>
>> Esteban A. Maringolo
>>
>> ps: When I finished writing this email, this was the progress...
>> 
>>
> 

-- 
Esteban A. Maringolo

[Pharo-dev] Standardized nomenclature for feature requests

[Esteban A. Maringolo]

Hi there,

Q: Is there a reason why Pharo (as a project) doesn't follow a
standardized nomenclature for features/request as other communities does?

So for instance something like PFR-005 (Pharo Feature Request) could be
"Truly headless images", PFR-006 "Pharo Bootstrapping", etc.

I can't really tell whether this would improve to the overall process,
but I wanted to know if this was already debated by the board and
dismissed, if it is something that wasn't considered at all, of if we
have something equivalent and what it is.


Regards,

Language examples:
JSR (Java Specification Requests) https://www.jcp.org/en/jsr/all
PEP (Python Enhancement Proposals) https://www.python.org/dev/peps/
RFC (Rust, Request for Comments) https://github.com/rust-lang/rfcs

Technologies:
BIP (Bitcoin Improvement Proposal) https://github.com/bitcoin/bips
EIP (Ethereum Improvement Proposal) https://eips.ethereum.org/










-- 
Esteban A. Maringolo



signature.asc
Description: OpenPGP digital signature

Re: [Pharo-dev] About the infinite debugger

[Esteban A. Maringolo]

El dom., 5 de ago. de 2018 17:28, Tim Mackinnon  escribió:

> Guys - this really needs attention - I’ve spend hours now trying to debug
> some code and most of it is in closing infinite debuggers. It makes a
> mockery of our tagline - “awesome debugging”.


We can change the tagline to "limitless debugging".

Re: [Pharo-dev] About the infinite debugger

[Esteban A. Maringolo]

Great news!

I hope this fixes it once and for all.

For some reason this bug bit me several times in several Pharo releases.

Thank you all for your dedication.

On 29/06/2018 11:48, Guillermo Polito wrote:
> Hi all,
> 
> during today's sprint we have been working with lots of people on the
> infinite debugger problem (https://pharo.fogbugz.com/f/cases/22085/). We
> have checked the emails sent in the latest month. Then, together with
> Quentin, Pablo, Pavel, Yoan we have been discussing and testing
> hypothesis all day. We have been also comparing the debuggers code
> between pharo 3/4 (where the bug was is present) and pharo 7, but this
> was not necessarily straight forward as the code is not the same and
> there is no easy diff...
> 
> ND, we have found that the problem may come from a wrong pragma
> marker. Just removing that pragma gives us back the same behaviour as
> in  Pharo 3/4. :D
> 
> https://github.com/pharo-project/pharo/pull/1621
> 
> I know that the exception handling/debugging has been modified several
> times in the latest years (some refactorings, hiding contexts...), we
> unfortunately don't have tests for it, so I'd like some more pair of
> eyes on it. Ben, Martin could you take a look?
> 
> Thanks all for the fish,
> Guille

-- 
Esteban A. Maringolo

Re: [Pharo-dev] [Pharo-users] [Ann] Iceberg v1.1.1

[Esteban A. Maringolo]

On 19/06/2018 09:06, Norbert Hartl wrote:

>> We can agree that there is no hard rule on versionning, do we? But I
>> try to follow the following guidelines (delta my own interpretation
>> that adds some subjectivity :P)
>> - Major Version will change when we break backwards compatibility
>> - Minor Version will change when new features are added
>> - Otherwise, patch version will change.
>>
> There is only one hard rule for me and that is knowing about the risk to
> take. So if we take the patch version it should only include important
> bug fixes and nothing else. I would argue that only #864, #862, #858 and
> #854 qualify for such a patch if at all. Not sure about #860 because the
> title is not specific enough. 
> The point for me is that I want my project to rely on something like
> 1.1.x because I don’t want anything to change that breaks my software.
> And I can tell you that most developers underestimate the side-effects
> of changes. 

+1 to this.

Only by introducing a new feature you MUST increment the minor version.

>> Now, this is the kind of subjective topic that starts a flamewar, but
>> I’d prefer to use my time on somewhat else ^^.
> 
> You may not like to talk about these things but I do. And you should
> listen. I have no use for an environment where people only care about
> coding new cool stuff.
> If it would be like this I would quit all my
> pharo businesses, move to mainstream and would use pharo only for
> hobbyist projects because that would be the level that can be met.

I've used commercial Smalltalks before Pharo and VW for the last year,
and although they're _ages_ behind some of the "modern" stuff in Pharo,
they never compromise version semantics regarding these things.

And if I give it a second thought I can point to other open-source
non-smalltak big projects/libraries which are also cool but also follow
strict versioning, and being bigger the cascade effect of changing
artifacts semantics is way bigger.


Please take this comment with a grain of salt, it's not a critic of all
the work done in Iceberg or other projects, but it seems that these kind
of "meta" (aka "PM", "strategy", or anything non-coding) discussions are
avoided or muted, and they shouldn't.


Regards,


-- 
Esteban A. Maringolo

Re: [Pharo-dev] Debugger Button Positioning

[Esteban A. Maringolo]

On 14/06/2018 15:13, Eliot Miranda wrote:
> Hi All,
> 
>      I've been using Pharo intensively for the first time, Pharo 7.
> Forgive me for starting with a complaint, but I don't have time to state
> all the things that are great about it; you already now ;-)
> 
> One thing I find painful is the positioning of the debugger
> into/over/through buttons.  Because these are above the context list,
> and you read the code like I do, one has to mouse further to reach
> them.  I find my focus is on the highlighted method, and my cursor is
> typically within it (I'm dong implementors, or senders, or just looking
> at the code).  Further, there's lots of space between the Source tab and
> the "Where Is?" and "Browse" buttons.  Doesn't it make more sense to put
> the into/over/through buttons between the Source tab and the "Where Is?"
> button?  If not, doesn't it make sense to put a copy of the buttons
> there where they're in much easier reach?

I agree with you in all your remarks, and IMO not only the buttons
position is suboptimal, also their shortcuts.

But AFAIR this was discussed some time ago when the GTDebugger was set
as the default debugger.

But the discussion was settled to "you can create your own". Which I
don't like, but it's fair enough. :)

Regards!


-- 
Esteban A. Maringolo

Re: [Pharo-dev] Updated syntax postcard

[Esteban A. Maringolo]

Thank you! It's really nice!

On 01/06/2018 07:56, Pavel Krivanek wrote:
> Hi,
> 
> for the Wikipedia article I prepared an updated version of Phar syntax
> postcard:
> 
> https://upload.wikimedia.org/wikipedia/commons/a/a7/Pharo_syntax_postcard.svg
> 
> Cheers,
> -- Pavel

-- 
Esteban A. Maringolo

Re: [Pharo-dev] IMPORTANT: ML Etiquette

[Esteban A. Maringolo]

On 28/05/2018 12:36, Tim Mackinnon wrote:
> Sent from my iPhone
>> On 28 May 2018, at 17:26, Stephan Eggermont  wrote:
>>> Sent from my iPhone
>> That supports NewsTap, which makes it easy to not top-post. I’m not sure
>> why lines are not broken though. 
> 
> I’ll try my best - but the normal iPhone mail client simply doesn’t work this 
> way - it top posts. 

I'm fine with top posting. Even when a thread has both top and
in-between replies.

What really bothers me is that top posting "hides" the huge list of
replies at the bottom. So a two line, top posted reply is a 500 lines of
quoted email below. Top posting should be limited to one quoted email
only. Otherwise you need to start referencing things by letters/numbers
or better... reply below :)


> I think we’re on a losing battle with this one.

I agree. But I'm not giving it away without a fight :P


Regards,

-- 
Esteban A. Maringolo

Re: [Pharo-dev] Pharo 7 on SqueakJS (demo)

[Esteban A. Maringolo]

Nice experiment!
The fact that it works it's a feat itself.

Maybe in the future with WebAssembly and a lighter/core image it will
became a viable alternative.



On 21/05/2018 07:01, Pavel Krivanek wrote:
> Hi,
> 
> with some tweaks mostly related to FFI and fonts, we are able to run
> Pharo 7 on SqueakJS VM.
> 
> Do not expect blazing performance. Currently, it is about two orders of
> magnitude slower than the native VM. 
> 
> https://pavel-krivanek.github.io/pharo/pharo.html
> 
> Cheers,
> -- Pavel

-- 
Esteban A. Maringolo

Re: [Pharo-dev] Fix Base64 madness for good

[Esteban A. Maringolo]

10/05/2018 16:42, Sven Van Caekenberghe wrote:
> Hi,
> 
> I propose the following:
> 
> https://pharo.manuscript.com/f/cases/21870/Fix-Base64-madness-for-good
> https://github.com/pharo-project/pharo/pull/1331
> 
> This is a much needed cleanup, IMHO. It is a breaking change however, since 
> it changes the signature (return type) of an existing method. 
> 
> #base64Decoded used to wrongly return a String, while that should be a 
> ByteArray since Base64 encoding is a way to encode bytes as ASCII text, hence 
> decoding it should give you back the original bytes.

Those who were using these methods expecting a string can send #asString
to the returned bytarray. Of course that would be wrong, but it would be
"as wrong as before", and hence, compatible.

So please go ahead and change it. Also, having a "proper" implementation
in a live environment serves a teaching vehicle for those learning how
stuff works.

Regards,

-- 
Esteban A. Maringolo

Re: [Pharo-dev] SortedCollection based on SortFunction [Re: SortedCollection>>reverse answers an inconsistent object]

[Esteban A. Maringolo]

I think sortfunctions are a great tool, with particular benefits if you
use it in the context of metamodels, like with Magritte descriptions.

Also I think it is more readable to use symbols/sortfunctions than blocks.

The only thing that should be guarded in the use of SortFunctions is the
handling of nil, a comparison with a nil object should fail noisily,
which currently doesn't by default AFAIR (I added the option to put nils
first or last in the resulting collection).

Note: Being myself an stubborn early optimizer I would make that
`SortedCollection new` returns a sorted collection with itself as the
default sortblock implementing #value:value: in SortedCollection. This
saves you from instantiating new objects other than the collection
itself for instances where sortblock is based on #<= as it currently is.

Regards,


On 25/04/2018 09:08, Denis Kudriashov wrote:
> Hi.
> 
> Now we have really nice SortFunction's machinery. We can simply write:
> 
> Object allSubclasses sorted: #name ascending
> 
> instead of: 
> 
> Object allSubclasses sorted: [:a :b | a name <= b name ].
> 
> And there is special kind of SortFunction which represent such block
> itself: 
> 
> 
> [:a :b | a name <= b name ] asSortFunction "==>  a
> CollatorBlockFunction".
> 
>  
> The power of first class functions is that they provide reusable
> composition features like:
> 
> 
> contacts sorted: #name ascending, #surname descending.
> contacts sorted: (#name ascending, #surname descending) reversed.
> 
> 
> (look at class comments for more examples).
> 
> It is all very cool and powerful but in the core Pharo still work with
> primitive blocks. 
> All sorting methods and SortedCollection are implemented in terms of
> sortBlock.
> So SortFunction's are adopted to block interface #value:value:.
> 
> And my proposal: 
> Let's replace sortBlock by sortFunction everywhere. Block will still
> work but it will be converted to function.
> It will open new possibilities to implement more features. 
> For example SortedCollection>>reversed would be trivial with
> sortFunction (see previous thread).
> 
> Drawback is extra dependency in collections. But we can extract
> SortedCollection and related functions into separate package which
> probably will allow reduce bootstrapped codebase.
> 
> I am not going to implement it right now. Just want to share this idea
> to see what's wrong with it.
> 
> Best regards,
> Denis

-- 
Esteban A. Maringolo

Re: [Pharo-dev] Do we kill the catalog?

[Esteban A. Maringolo]

On 20/04/2018 14:42, Hernán Morales Durand wrote:
> Hi Stef,

>> Do you think that editing STON is easier than a class? I think that we
>> should have a button.
>> Look people do not care about posting their project into the repo.
>> May be we need a crawler?

> That's why I try to do with PI https://github.com/hernanmd/pi
> 
> It's 100% command-line, which I know smalltalkers don't love.
> 
> However after working with Python, R, Perl, etc. I saw the world
> expects a pretty standard package installation pattern.

+1

> I feel (outsider) people really don't care if there is a Catalog,
> StHub, PepeHub.

We have the right (and probably the reasons) to do things "our way", but
it shouldn't surprise us if outsiders and newcomers reject that way
because it feels weird, even if is better than what they're used to.


Regards,


-- 
Esteban A. Maringolo

[Pharo-dev] [OT] Reminder about quoting/top-posting

[Esteban A. Maringolo]

Hi,

Please apologize the digression, but these days there were a lot of
interesting threads with LOTS of replies from different members.

Can I ask for more trimming of the quoted text and/or emails replied to?

The follow up of some replies was hard because they were nested deep
into a chain of previous quotes, or in the case of top-posters, they
keep the replied emails accumulating in the bottom, causing a scroll
down to find nothing else was there.

Thanks!


-- 
Esteban A. Maringolo



signature.asc
Description: OpenPGP digital signature

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
> <emaring...@gmail.com> 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?

[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
> <emaring...@gmail.com> 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] 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

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

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
> <emaring...@gmail.com> 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 <pdebr...@gmail.com> 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] 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 <pdebr...@gmail.com> 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] Multiple Inheritance

[Esteban A. Maringolo]

Are you in the "release the Kraken" mood? :)

I haven't used stateful traits, and barely traits at all (when I wanted
to use it extensively the tools weren't ready).
But I see Traits more as a mix-in approach, rather than a multiple
inheritance one.

Also, in my experience building software with Smalltalk, I didn't have
the need to use multiple inheritance, but I did have the need to reuse
some behavior like Singleton, "named objects" (implementors of
#name/#name:), and have "Interface" like behavior (as in Java's
`implements ABCInterface`) I can query, and all that can be done with
Traits and, IMO, it better represents the purpose of a "trait" rather
than a multiple inheritance mechanism.

Regards!


On 09/04/2018 11:09, Sean P. DeNigris wrote:
> I was just thinking about all the freedom brought by stateful traits, and the
> thought occurred: why not just simplify and remove another hurdle by having
> multiple inheritance with the conflict resolution and scoping of traits?
> 
> Forgive me if I'm missing something obvious…
> 
> 
> 
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
> 

-- 
Esteban A. Maringolo

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

[Esteban A. Maringolo]

ail.com>
> <mailto:esteba...@gmail.com <mailto:esteba...@gmail.com>>> wrote:
> >      > Hi,
> >      >
> >      > yesterday someone posted an article on HN about the
> Pharo MOOC
> >     and there has
> >      > been some negative posts there.
> >      > I would like to call people who can have the time to
> answer there
> >     and help
> >      > to explain better and also contribute to contest that FUD
> >     someones (we know
> >      > who they are… sames as always) are spreading.
> >      >
> >      > here the link :
> https://news.ycombinator.com/item?id=16754872
> >      >
> >      > (this is not loosing time, people searching for Pharo
> will likely
> >     see this
> >      > kind of messages… at least we need to offer our point
> of view)
> >      >
> >      > cheers!
> >      > Esteban
> >
> > --
> > Cheers,
> > Alex
> 
> 

-- 
Esteban A. Maringolo

Re: [Pharo-dev] AnnouncementSubscription and Ephemerons

[Esteban A. Maringolo]

Thank you for the detailed info Stef.

Regards!
Esteban A. Maringolo


2018-04-01 16:16 GMT-03:00 Stephane Ducasse <stepharo.s...@gmail.com>:
> My last email on VM topics...
>
> Hi esteban
>
> Just for the record, our team spent a lot of engineering time and
> money on Pharo.
> May be I forgot some people. Often we bent research projects to
> squeese in Pharo activities.
>
> - Pavel 1 year paid for bootstrap and general improvements
> - Denis 2 years paid for TelePharo (for research projects)
> - Igor 4 years paid for athens, SDL, VM Build, TxText
> - Christophe 5 years bootstrap, ci, infras, plauncher, cargo
> - Clement two years as young engineer on compiler/VM
> - Clement 6 months on Sista
>
> - Camillo 3 years for his Phd
> - Guille 3 years for his Phd
> - Pablo 3 years for his Phd
> - Mariano 3 years for his Phd
> - Clement 3 years for thisPhd
>
> - Guille two years on various improvements
> - Me several years
> - Marcus several years
> - Damien on side project
> - Esteban 4 years by Inria
>
> - Nicolas Passerini got paid by the consortium 9 months
> - Guillermo paid 6 months for database
> - you and mariano got paid for side projects for a couple of months
>
> Right now only Esteban is paid by the consortium because this what the
> consortium
> can pay!
>
> If I sum up Inria put a lot of money on the table compared to the
> users and people
> benefitting from Pharo. But this is like that.
>
> So I think that the consortium is a positive thing. Some people may
> think the contrary.
> Now do not expect miracles. A single guy cannot do much.
> Retrospectively I think that
> I made a mistake pushing to have tools for git. We should have go the
> filetree way
> and command line and gain 18 months of work. But I cannot be right all
> the time.
>
> Now if all the companies doing Pharo would put money on the table then
> we could have
> another full time engineer working to improve the situation. I hope
> that this will happen.
>
> Then about the VM: a VM is a complex piece of engineering.
> And in the open-source community people apparently like to put in addition
> not good process and extra constraints (super compatibility, different
> dialects), not good communication,
> So we end up with a not good situation.
>
> Now I will not read and send any emails about the VM in the future. I
> have a set a filter to
> automatically trash any emails on the topic. So if you send me an
> email and you see now reaction it is normal.
> I think that we make no progress and we are even on regression on this part.
>
> We will talk with the consortium members and asked them what is the priority
> and if the VM is one of them, then we will have to take real decisions
> to make progress.
> Now since we cannot form someone on VM core rapidly we will see what are the
> options. But to me what is clear is that the situation cannot continue
> to be like that.
> We cannot not control our process.
>
> Stef
>
>
> On Sun, Apr 1, 2018 at 6:02 PM, Esteban A. Maringolo
> <emaring...@gmail.com> wrote:
>> Stef,
>>
>> I encourage you to disclose as much details as possible.
>>
>> For "bystanders" as myself, it is, a Pharo _user_ that always thinks
>> of Pharo as the first option but
>> doesn't contribute to the core of it,  all this discussions only add
>> noise and concerns about the
>> stability of the whole Pharo ecosystem.
>>
>> I've always had  the impression that Pharo is heavily dependent on
>> INRIA's/government institutions,
>> which in the end depend on political decisions instead of
>> "market/profit" objectives.
>> With the support of members of the Consortium I thought this had changed, but
>> reading your statements it seems it is not enough.
>>
>> It is known you don't have the best temper, but it is also known you
>> strive to get the best for Pharo,
>> so if you're also aware of that you can avoid restraining yourself,
>> and say what you have
>> in mind trying to not make personal accusations.
>>
>> I'd prefer a brutal and noisy truth instead of false quiet calm.
>>
>> I hope this helps.
>>
>> Regards,
>>
>> Esteban A. Maringolo
>>
>>
>> 2018-04-01 10:16 GMT-03:00 Stephane Ducasse <stepharo.s...@gmail.com>:
>>> I will not reply publicly to this email because I think that it will get 
>>> worse.
>>> So I will not talk publicly about anything related to the Pharo VM in
>>> the Pharo mailing-list and any other lists.
>>> I will put a filter and trash emails automatically. Like that I will
>>> get touch

Re: [Pharo-dev] AnnouncementSubscription and Ephemerons

[Esteban A. Maringolo]

Stef,

I encourage you to disclose as much details as possible.

For "bystanders" as myself, it is, a Pharo _user_ that always thinks
of Pharo as the first option but
doesn't contribute to the core of it,  all this discussions only add
noise and concerns about the
stability of the whole Pharo ecosystem.

I've always had  the impression that Pharo is heavily dependent on
INRIA's/government institutions,
which in the end depend on political decisions instead of
"market/profit" objectives.
With the support of members of the Consortium I thought this had changed, but
reading your statements it seems it is not enough.

It is known you don't have the best temper, but it is also known you
strive to get the best for Pharo,
so if you're also aware of that you can avoid restraining yourself,
and say what you have
in mind trying to not make personal accusations.

I'd prefer a brutal and noisy truth instead of false quiet calm.

I hope this helps.

Regards,

Esteban A. Maringolo


2018-04-01 10:16 GMT-03:00 Stephane Ducasse <stepharo.s...@gmail.com>:
> I will not reply publicly to this email because I think that it will get 
> worse.
> So I will not talk publicly about anything related to the Pharo VM in
> the Pharo mailing-list and any other lists.
> I will put a filter and trash emails automatically. Like that I will
> get touched anymore by what I see.
>
> You may think that I'm wrong. I'm probably.
>
> Now just to make clear: I funded all the PhD of Clement, and all the
> work of Igor around the VM.
> And many other engineers and PhD (C. Bruni, Sophie, ...)
> I'm fighting to make the Pharo consortium working so that we can pay
> people like Esteban
> (Esteban is not working in Pharo just because he cannot find a job
> outside our little community and this
> is the case for many other people) and other people.
>
> Stef
>
> On Sun, Apr 1, 2018 at 2:33 PM, Nicolas Cellier
> <nicolas.cellier.aka.n...@gmail.com> wrote:
>>
>>
>> 2018-04-01 11:36 GMT+02:00 Stephane Ducasse <stepharo.s...@gmail.com>:
>>>
>>> Hi Torsten
>>>
>>> Thanks for this question.
>>>
>>> Ephemerons do not work in Pharo sadly and we know it. We cannot then
>>> take advantage of them.
>>> What you see is in fact a degradation of the situation around the VM. :(
>>> We are concerned about this but the path for our future in this domain
>>> is unclear.
>>>
>>
>> Hi Stephane,
>> the future is in your hand.
>> Put milestones on opensmalltalk-vm, open new entries on opensmalltalk-vm
>> issue tracker, put engineering force to solve pharo-specific build failures.
>> In one word, help us to help you.
>>
>> So could you please explain what did you do exactly to help ephemerons being
>> implemented in spur, and what are the forces couter-acting your efforts?
>>
>>
>>>
>>> What is clear is that we will reduce the number of Plugin (as pablo
>>> did for freetype) and use FFI.
>>> But FFI callbacks are not really good. And we need a threaded VM. Now
>>> nothing happens on this front.
>>>
>>
>> Yes, we all want that!
>> It's just that it does not happen by magic nor handwaving.
>>
>>>
>>> Let us face it there is a bad energy around. After years of discussion
>>> our engineers
>>> are still struggling and slowed down because of the dispersion of plugin
>>> code.
>>> In addition, from what I understood there is no development branch :)
>>> amazing is not it in 2020!
>>>
>> How sarcasms are going to  federate and encourage people to make progress?
>> What can you obtain with this sort of sentence but further splitting the
>> community?
>> Is it your goal?
>>
>>>
>>>
>>> On another scale, since 1 year, I was focusing on making that our
>>> institute offers a permanent position to Clement but I failed
>>> because the forces against where too strong (politics) and clement
>>> should reapply next year.
>>> Now to improve his CV, clement is doing a postdoc at VUB and will
>>> start working on Truffle (the VM of Oracle)
>>> and continue to work part time on Sista.
>>> This is not that bad,  like that he will gain experience on other
>>> systems and in the future
>>> we will be in the position to see if there are real alternatives for
>>> us. May be writing a new VM
>>> on top of other existing infrastructure is the way to go. We will see
>>> in the future.
>>>
>>
>> Unfortunately, the rules of French institutions certainly do not help you...
>> Maybe Truffl

Re: [Pharo-dev] New Files in Pharo - Migration Guide, How To's and examples

[Esteban A. Maringolo]

2018-03-19 17:42 GMT-03:00 Nicolas Cellier <nicolas.cellier.aka.n...@gmail.com>:
> 2018-03-19 21:21 GMT+01:00 Denis Kudriashov <dionisi...@gmail.com>:
>>
>> 2018-03-19 20:39 GMT+01:00 Esteban A. Maringolo <emaring...@gmail.com>:
>>>
>>> 2018-03-19 16:32 GMT-03:00 Denis Kudriashov <dionisi...@gmail.com>:

>>> > aStream buffered.
>>> I'd only change this one, to #beBuffered.

>> But #be sounds like it modifies receiver.
>> But idea is same as #reversed or #sorted for collections.
> -1 for beBuffered, it's not about adding states to the stream.
> As Denis said, it's a transform producing a new stream.


I didn't understand it was returning a transformed instance, I
actually thought it was the opposite, so if that is the case then
Denis' suggested selectors are fine.

Thanks for the clarification.

Esteban A. Maringolo

Re: [Pharo-dev] New Files in Pharo - Migration Guide, How To's and examples

[Esteban A. Maringolo]

2018-03-19 16:32 GMT-03:00 Denis Kudriashov <dionisi...@gmail.com>:
>
> Hi Guille.

> What you think to add helpfull converting methods?

I'd like them. Anything that saves me from passing a string literal as
parameter is good. :)

> aStream buffered.

I'd only change this one, to #beBuffered.

> aStream withLineEnding: String cr.
> aStream withPlatformLineEnding.

These two seem ambiguous to me, #with prefix signals something else in my head.

I'd remove the "with" and use instead:

  aStream lineEnding: String cr.
  aStream usePlatformLineEnding.

Regards!



Esteban A. Maringolo

Re: [Pharo-dev] Ctrl+W in tabbed windows (GT inspector, browser/Calypso)

[Esteban A. Maringolo]

2018-03-19 7:08 GMT-03:00 Ben Coman <b...@openinworld.com>:

> On 19 March 2018 at 17:07, Petr Fischer <petr.fisc...@me.com> wrote:
>> Is everyone in comfort with the idea that Ctrl+W should close the actual
>> tab, and if there is no tab in the window (or actual tab is the last tab),
>> then close the window?
>
>
> Actually I never knew that shortcut, but I will now.
> I see it works that way in both Chrome and InternetExplorer and web browsers
> are a good benchmark.

It's the sibling of Ctrl+Tab and Ctrl+Shift+Tab to move forward or
backward in a list of tabs.

I use it a lot.


Esteban A. Maringolo

Re: [Pharo-dev] [Pharo-users] Something is happening...

[Esteban A. Maringolo]

Do we have any metrics on the number of visits we get on the pharo.org
website, which parts are the most visited, etc?

The same regarding web downloads, and so on. I understand that CI can
distort download count if using only access logs, but certainly if we
count a download through the webpage as a "conversion" (and track it
somehow) we would have a better idea how big this is becoming.

But back to your point and as a bystander these days, it is very hard
to be aware of everything that's going on in the Pharo world, and not
because of the associated noise, because there is actually a lot of
things going on. :)

Regards,

Esteban A. Maringolo


2018-03-13 4:27 GMT-03:00 Marcus Denker <marcus.den...@inria.fr>:
> Hi,
>
> There is something odd happening… or better: There is *a lot* happening.
>
> Just one example: for the Newsletter, the original idea was to send out once
> a month a post with 3 things, some of them recycled (e.g. pointers to
> existing projects, re-use “success stories”, things like that.
>
> Now already some months ago I had to add “and here are some other
> interesting announcements, blog posts, videos”.
>
> But this month, the list of things for the newsletter TODO list contains
> over 60 entries. With the exception of maybe 5, these are just things that
> happened between sending the February newsletter and today.
>
> Newsletter March should be ready till this thursday, I hope, subscribe or
> read the oder ones here: http://newsletter.pharo.org
>
> Marcus

Re: [Pharo-dev] renaming Matrix to 2dArray

[Esteban A. Maringolo]

I thought you couldn't name classes starting with numbers.

If that wasn't the case I think Array2D would be a better option.

Regards,


Esteban A. Maringolo
Esteban A. Maringolo


2018-03-09 17:46 GMT-03:00 Stephane Ducasse <stepharo.s...@gmail.com>:
> Hi
>
> long time ago I renamed 2DArray as Matrix. Now our Matrix class does
> not support any of the Matrix operations, so I was thinking that to
> avoid confusion (people should use polymath) we should rename it back
> to 2DArray.
> What do you think?
>
> Stef
>

Re: [Pharo-dev] How to use git with gitfiletree

[Esteban A. Maringolo]

2018-03-02 11:12 GMT-03:00 Peter Uhnák <i.uh...@gmail.com>:
> you mean that gitFILETREE:// would somehow use TONEL? That hardly seems like
> a good idea.
>
> However there's gitlocal:// ... (which iirc handles both) but I think that's
> iceberg specific.

Sometimes I feel I need something like "The ultimate guide to SCM with
Pharo" to cover all options in between of the good'ol Monticello to
the automagical Iceberg with Github (and maybe others like Gitlab,
etc.).

Regards,

Esteban A. Maringolo

Re: [Pharo-dev] #valueWithPossibleArgs:, #valueWithEnoughArguments:, and #cull:

[Esteban A. Maringolo]

2018-02-23 14:50 GMT-03:00 Stephan Eggermont <step...@stack.nl>:
> Sven Van Caekenberghe <s...@stfx.eu> wrote:

>> Cleanups at the level of Object are particularly valuable.
>
> It needs to be done in a way that is sustainable. That means with a code
> rewrite rule. Deprecations are not enough. The number of people who can
> migrate forwards older code is very small, especially as we are missing
> crucial parts of design discussion that took place on slack and were not
> copied to mail.

Why not both?

With a noisy enough deprecation warning and a handy rewrite rules
script it would ease the transition.

AFAIR the procedure was to mark as deprecated in one release and
remove completely in the next one.

Best regards!


Esteban A. Maringolo

Re: [Pharo-dev] About method comments

[Esteban A. Maringolo]

2018-02-09 8:10 GMT-03:00 Sven Van Caekenberghe :
> name
>   "Returns the receiver's name"
>   ^ name
>
> Would also pass a simple test, while it is quite useless.
>
> I would say that any public, non-trivial methods need a comment.

Commenting an accesor is redundant, IMO.

And rename refactorings usually don't rename the comments (hopefully).

However I think that having a public guideline on how to comment
methods would be positive for the community (if these rules are
consensual).
After that some tools can use these guidelines to generate comments on
their own, or if you don't know how to comment, simply copy the
templates from the guide.

E.g. Private methods in Dolphin always start with "Private - ...", if
you remove the "private" category from the method (methods can belong
to multiple categories), then it removes the "Private - " prefix from
the comment as well.

Regards,

--
Esteban.

Re: [Pharo-dev] printString of fileReference sucks!

[Esteban A. Maringolo]

Hi Stef, all,

I've seen this "inconsistency" as well. The current printSting tries
to be descriptive but isn't handy to work with.

I would go one step further and have no #asFileReference suffix nor
File @ prefix, it is:

'/Users/ducasse/Workspace/FirstCircle/MyBooks/Bk-Writing/PharoBooks/Booklet-AMiniSchemeInPharo/_result'
asFileReference printString
>>> '/Users/ducasse/Workspace/FirstCircle/MyBooks/Bk-Writing/PharoBooks/Booklet-AMiniSchemeInPharo/_result'


If for some reason the option chosen is to keep the current
printString then the printString should be:
>>> 'File @ 
>>> ''/Users/ducasse/Workspace/FirstCircle/MyBooks/Bk-Writing/PharoBooks/Booklet-AMiniSchemeInPharo/_result'''

It is, a string with three tokens, the class name, the @ symbol and a
string as an argument, that way you can evaluate the result back.

I prefer the first one, it enables you to work with files on
workspaces, if you're using inspectors the printString doesn't matter
much, since you're dealing with a specialized tool and there is no way
you can confuse a FileReference with a regular String instance

Best regards,
Esteban A. Maringolo


2018-02-02 16:12 GMT-03:00 Stephane Ducasse <stepharo.s...@gmail.com>:
> Hi
>
> '/Users/ducasse/Workspace/FirstCircle/MyBooks/Bk-Writing/PharoBooks/Booklet-AMiniSchemeInPharo/_result'
> asFileReference printString
>>>>  "File @ 
>>>> /Users/ducasse/Workspace/FirstCircle/MyBooks/Bk-Writing/PharoBooks/Booklet-AMiniSchemeInPharo/_result"
>
> so either we add @ one File or we redefine printString one reference to be
>
> '/Users/ducasse/Workspace/FirstCircle/MyBooks/Bk-Writing/PharoBooks/Booklet-AMiniSchemeInPharo/_result'
> asFileReference so that we can do something with the printString
> result.
>
> What do you think?
> Guille is it what we talked together?
>
> Setf
>

Re: [Pharo-dev] Blame support P7

[Esteban A. Maringolo]

2018-01-14 8:04 GMT-03:00 Stephan Eggermont :
>
> Sven Van Caekenberghe  wrote:
>
> > (1) what non-trivial code is actively maintained from a single code base
> > between Pharo, Squeak and Cuis ?
>
> That is nice, but too limited a question
>
> What about the need to maintain non-trivial large code bases between
> multiple smalltalks? If we only limit ourselves to open source, just look
> at Glorp and PDFTalk.

I wouldn't use Glorp as a good example of multi-dialect portability.
It has safeguards and "ifs" all around the code, but it goes more in
the direction of making the dialects as much VW compatible as
possible, instead of being truly dialect neutral like Seaside is, and
have the proper "adapter" layer and packaging.

Regards!

Re: [Pharo-dev] Compiler Explorer (for the Compiler guys) #offtopic

[Esteban A. Maringolo]

Dolphin's debugger was what came to my mind, it had the "dissasembly" way
of debugging VM bytecode.
It doesn't provide was native code ASM, and as I understand GTInspector
neither.

Regards!

Esteban A. Maringolo

2017-10-18 6:55 GMT-03:00 Dimitris Chloupis <kilon.al...@gmail.com>:

> Yeap GTInspector was the first thing that came to my mind , great tool :)
>
> On Wed, Oct 18, 2017 at 9:37 AM Tudor Girba <tu...@tudorgirba.com> wrote:
>
>> Hi,
>>
>> This is already available since some time in the GTInspector. You can
>> just inspect a compiled method. You will get both the bytecode and the AST
>> (with source tracking, too). In fact, this was one of the original reasons
>> why GTInspector exists: I wanted to figure out how the AST is structured so
>> that I can write queries against it :).
>>
>>
>> Cheers,
>> Doru
>>
>>
>> On Oct 17, 2017, at 10:03 PM, Esteban A. Maringolo <emaring...@gmail.com>
>> wrote:
>>
>> I'm sure we could do this with ease, because we already can see the
>> bytecodes.
>>
>> https://godbolt.org/
>>
>> Regards!
>>
>> Esteban A. Maringolo
>>
>>
>> --
>> www.tudorgirba.com
>> www.feenk.com
>>
>> "The coherence of a trip is given by the clearness of the goal."
>>
>>
>>
>>
>>
>>

[Pharo-dev] Compiler Explorer (for the Compiler guys) #offtopic

[Esteban A. Maringolo]

I'm sure we could do this with ease, because we already can see the bytecodes.

https://godbolt.org/

Regards!

Esteban A. Maringolo

Re: [Pharo-dev] shameless request: please star pharo-project/pharo in GitHub :)

[Esteban A. Maringolo]

Thanks Paul.

Esteban: Shouldn't the repo be marked as "Smalltalk" language?

Performing a search on repos of "Smalltalk" there are several ones
with less stars than Pharo, and it doesn't show up.

https://github.com/search?o=desc=language%3ASmalltalk=stars=Repositories=%E2%9C%93

Esteban A. Maringolo


2017-10-09 13:47 GMT-03:00 Paul DeBruicker <pdebr...@gmail.com>:
> for the lazy:
>
> https://github.com/pharo-project/pharo
>
>
>
>
>
> EstebanLM wrote
>> just to get better rating ;)
>>
>> Esteban
>
>
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>

Re: [Pharo-dev] String Interpolation

[Esteban A. Maringolo]

2017-10-04 16:49 GMT-03:00 Denis Kudriashov <dionisi...@gmail.com>:
> 2017-10-04 21:38 GMT+02:00 Esteban A. Maringolo <emaring...@gmail.com>:

>>> It is not compiled time but behaviour is very close to it.
>>> The trick is that first time execution will replace full expression with
>>> the result as literal (the receiver of #asMethodConst). So at second time it
>>> will be just literal reading.

>> It is weird that a regular message send makes the returned value a method
>> constant.
>> How is that cleaned up? Do I have to search for all the methods that
>> contain such message send?

> What the problem? This message is a tool. You use it when you need it. When
> you modify the method the value is cleaned.
> Nice thing is that it not requires special syntax. And you can debug
> expression as normal part of method.

I don't see any problem, I just said "weird".

It's a "special return" message send. A trick of sorts, no different
than #doesNotUnderstand: or other special selectors.

Regards,

Esteban A. Maringolo

Re: [Pharo-dev] String Interpolation

[Esteban A. Maringolo]

2017-10-04 6:46 GMT-03:00 Denis Kudriashov <dionisi...@gmail.com>:

> Hi Igor.
>
> Did you see that we have now #asMethodConstant?
>
> DateAndTime now asMethodConst
>
>
> It is not compiled time but behaviour is very close to it.
> The trick is that first time execution will replace full expression with
> the result as literal (the receiver of #asMethodConst). So at second time
> it will be just literal reading.
>
>
It is weird that a regular message send makes the returned value a method
constant.
How is that cleaned up? Do I have to search for all the methods that
contain such message send?

Dolphin had the ##() syntax, which basically creates a method constant, but
it is evaluated right away.

So you could write the seconds in a day as ##(60*60*24), or, of course, any
more complex expression. But the difference is that it is resolved at
compile time.

However I don't see how this relates with the String interpolation :)

Esteban A. Maringolo

Re: [Pharo-dev] Never-ending computations and cmd-dot

[Esteban A. Maringolo]

I think the problem doesn't come from a lot of Ctrl+., but for another
unhandled exception.

I've been bitten by that from time to time, usually in the context of
a MessageNotUnderstood exception that gets recursive.

Regards,

Esteban A. Maringolo


2017-09-25 19:16 GMT-03:00 Hernán Morales Durand <hernan.mora...@gmail.com>:
> Hi,
>
> Guys I have the situation you will recognize in the attached picture:
> A never-ending recursive computation which generate zillions of
> pre-debug windows when cmd-dot key is pressed.
>
> Is there any setting, or any way to put a monitor to detect that
> cmd-dot is creating too many windows so will pop-up just one or two?
> Maybe someone researched this issue, does it makes sense?
>
> Cheers,
>
> Hernán

Re: [Pharo-dev] Maybe better pinning messages? (inspired by [Pinning Objects in Pharo])

[Esteban A. Maringolo]

I understand it's not about the intention revealing of the selector, but
about not making #pin:/#unpin: a kind of "reserved selector" as many
implemented in Object.

Regards,

Esteban A. Maringolo

2017-09-11 9:16 GMT-03:00 Esteban Lorenzano <esteba...@gmail.com>:

> yes, me :)
>
> I do not see a reason to change them, tbh.
> for me they are comprensible as they are now and it does not adds more
> information pinInMemory or pinMemory.
>
> Esteban
>
>
> On 11 Sep 2017, at 11:56, Denis Kudriashov <dionisi...@gmail.com> wrote:
>
> Anybody else?
>
> 2017-08-31 10:29 GMT+02:00 Pavel Krivanek <pavel.kriva...@gmail.com>:
>
>>
>>
>> 2017-08-31 10:24 GMT+02:00 Denis Kudriashov <dionisi...@gmail.com>:
>>
>>> Hi.
>>>
>>> We now have very generic message names:
>>> - pin
>>> - unpin
>>> - setPinned:
>>> - isPinned
>>>
>>> Problem that they collide with possible domain related names.
>>> For example I implemented pinning of tabs in Calypso and I found that I
>>> overrides #pin and #isPinned messages. Then I fix it with different names.
>>> Probably menus also uses pin word but without overrides
>>>
>>> What you think about renaming pinning messages? Something like:
>>> - pinMemory
>>>
>>
>> I would use pinInMemory
>>
>> -- Pavel
>>
>>
>>> - unpinMemory
>>> - isMemoryPinned
>>> - setPinnedMemory:
>>> - pinMemoryDuring: (if we will introduce it)
>>>
>>> I think it is easy to do now because not much code uses pinning
>>>
>>
>>
>
>

Re: [Pharo-dev] Lowering the pain of newbies

[Esteban A. Maringolo]

2017-08-21 15:39 GMT-03:00 Peter Uhnák <i.uh...@gmail.com>:
> I'd prefer to not use `setName:` nor `setClassName:` as `setX:`/`setX:Y:` is
> often used as a constructor initialization pattern (as per Kent Beck's
> Smalltalk book).

I use setX: with the same purpose, as per the same book recommendation.

But isn't #name: (or #setName:) in Class used in the context of
initialization only?

> Maybe `changeNameTo:` to explicitly state the intent?

Although I don't like the "change" prefix when it's a one way
operation, that selector is unambiguous as it gets.

>> It indirectly becomes some sort of "reserved word" of the language.
>
> Class has many such methods (and I've destroyed my image many times before I
> subconsciously learned to avoid them), but only name tends to be problematic
> so introducing "special" methods for meta methods seems pointless, as a
> person doing metaprogramming would (must) take the care anyway to
> distinguish on which side they are working on.

+1


Esteban A. Maringolo

Re: [Pharo-dev] Lowering the pain of newbies

[Esteban A. Maringolo]

I avoid get/set prefixes in method selectors, however it is a "good
practice pattern" the use of the "set" prefix as a private accessor.

I use it to build initialized instances,

MyClass class>>#attribute: anObject
  ^self new setAttribute: aString

In some cases MyClass doesn't have the `#attribute:` setter because
it's not meant to be modified externally.

In the case of the `name` setter for a class, adding the `class`
prefix is redundant, so I think that `setName:` is the right selector
to use.

It's like the Clipboard class, that has the `clipboardText:` selector
instead of `text:` or something similar, but without the redundant
`clipboard` prefix.

But without diverting from the main topic, I think that the `name`
accessor is one of the things that causes a lot of trouble because of
unanticipated side effects. It indirectly becomes some sort of
"reserved word" of the language.

Also `name` is a common property in many domain objects, and creating
the accessors will create name:/name1 selectors, which is confusing
for newcomers as well, because they'd expect the #name getter instead
of #name1.

Regards,

Esteban A. Maringolo


2017-08-21 9:42 GMT-03:00 Dimitris Chloupis <kilon.al...@gmail.com>:
> its inconsistent to start using (set) in front of the name of methods and
> unnecessary
>
> className:
>
> makes more sense to me
>
> Another way to do this instead have something like classMetaData which can
> be a dictionary containing all the data like name of the class, method
> dictionary etc this way we ensure that what happened with name does not
> happen with other methods too that may find themselves in a name conflict by
> an unaware user.
>
> Or we can provide both ways or something else.
>
> Class name has caused me pain too and I am no newbie , when I was making an
> API for Blender it clashed with the name of the 3d objects. So this is
> definitely not newbie orientated problem , its a fundamental problem.
>
> I dont mind which solution you guys follow , afterall its easy to solve
> cause its easy to override any solution I don't like. The beauty of
> Smalltalk :)
>
> On Mon, Aug 21, 2017 at 11:05 AM Marcus Denker <marcus.den...@inria.fr>
> wrote:
>>
>>
>> > On 20 Aug 2017, at 23:48, Brad <bsselfri...@gmail.com> wrote:
>> >
>> > I vote for setClassName:
>> >
>>
>> setName: is better because this is what is there since many many years…
>> and by just using it
>> we must need to deprecate one method, not two.
>>
>> Marcus

Re: [Pharo-dev] Lowering the pain of newbies

[Esteban A. Maringolo]

What are the odds?

The ability to break a system in a few steps seems to be an inherited trait.

My daughter (2 years old) was randomly punching my keyboard and caused
a segfault that I couldn't reproduce afterwards.

Regards!


Esteban A. Maringolo


2017-08-17 16:52 GMT-03:00 Stephane Ducasse <stepharo.s...@gmail.com>:
> Hi guys
>
> my son coded in Pharo 60
>
> testGuessUrlPart
>
>   |dg8|
>   dg8 := GameItem new;
>   name: 'Dragon Quest VIII : Journey Of The Cursed King';
>   console: 'PS2'.
>self assert: dg8 guessUrlPart equals:
> 'dragonquestviiijourneyofthecursedking'
>
> and guess what he broke the system.
>
> We should not accept such kind of behavior.
> name: should not change the name of the class.
>
> I do not know the solution but I fear when I will teach 160 students this 
> fall.
> We should make sure that Pharo is not a system only for experts!
>
> any idea is welcome
>
> https://pharo.fogbugz.com/f/cases/20322/name-sent-to-a-class-SHOULD-NOT-automatically-rename-and-destroy-the-class
>
> Stef
>

Re: [Pharo-dev] [Pharo-users] including Pillar in Pharo image by default

[Esteban A. Maringolo]

You hit several birds with one single mail.

2017-08-14 13:34 GMT-03:00 Tim Mackinnon <tim@testit.works>:
> Jimmie et al. nicely reasoned arguments - and Doru's point about controlling
> the syntax is an interesting one that I hadn’t thought about.
>
> Personally, I find having too many similar syntax’s confusing - contributing
> to things is hard enough - having to remember that its !! Instead of ## and
> “” instead of ** is just frustrating for me.

+1

Not only for docs, most platforms like Slack/Discord share the syntax,
so now I'm getting "muscle memory" when typing literals using the
backtick (`) character, quoting with > or pasting snippets using ```

> Sure, maybe we were first with Pillar, but for me, lots of programming is in
> other languages, and I use Smalltalk where I can, and a hybrid of multiple
> languages and projects is often the reality - so a lowest common denominator
> of Markdown is just easier. The fact that we are quite close to what our
> colleagues in other languages use (regardless of what Python has chosen), is
> quite interesting.

This helps building "bridges" with other communities.

The language as a means of exchange is always the lowest common denominator.
As long as it's "efficient enough" then I vote to use what other
communities use.

> That said, if the community wants to stick to its gun’s thats fine - I will
> probably still investigate how to use Commonmark for myself, and will still
> contribute to Pillar docs where I can (and curse history) - but I think we
> are long better off trying to join emerging standards where we can
> particularly if they aren’t our core language thing. And it just makes it
> less frictionless for ourselves and newcomers.

The "Not Invented Here" syndrome is strong among Smalltalkers, it's
important to be aware of this bias and think more than once whether
eating our own dogfood adds value to the core of what Pharo brings.

I think we missed some good years fighting with our own SCM and in the
end git (or any other file based SCM) prevailed, even when it has
limitations.

Pareto (80-20) for everything non-core business should be a guide.

> Of course, if we were to move, we would need to translate a lot of quality
> docs to a new format - but I would be up for contributing to that if that
> was a deciding factor.

There are some Markdown exporters AFAIK, or it could be written.


Esteban A. Maringolo

Re: [Pharo-dev] Add JSONSchemas to NeoJSON

[Esteban A. Maringolo]

Sven is still the developer and maintaner of NeoJSON.

It would be nice to have JSON Schemas in NeoJSON. You could abort the
read of a stream if the schema is invalid, without
having to build the whole object tree or to parse the whole stream.

Regards!

Esteban A. Maringolo


2017-08-12 17:04 GMT-03:00 henry <he...@callistohouse.club>:
> Is Sven still working on NeoJSON? I want to help expand it to use
> JSONSchemas.
>
> https://spacetelescope.github.io/understanding-json-schema/
>
> I was looking at ASN1Module in Cryptography...
>
> - HH

Re: [Pharo-dev] fixing the tab morph

[Esteban A. Maringolo]

I liked the original trapezoid shape more than the squared version,
and if there is going to be a variable length (autosized) it should
have a maximum width setting, and leave the "variable width" tab for
the end.

There's some "muscle memory" in any UI, and having tabs (or any UI
component) that change size depending on the content can mislead you,
plus it can alter the UI "harmony".
It's no surprise web browsers "shrink" the width keeping a
proportional width, but never go full width, even when there is screen
state available.

Regards,

Esteban A. Maringolo



2017-08-07 15:18 GMT-03:00 Denis Kudriashov <dionisi...@gmail.com>:
> Would be nice to have autosized tabs
>
> 2017-08-07 19:18 GMT+02:00 Cyril Ferlicot D. <cyril.ferli...@gmail.com>:
>>
>> Le 07/08/2017 à 17:47, Esteban Lorenzano a écrit :
>> > Hi,
>> >
>> > So… summer project (to do when there is too much hot to go outside): fix
>> > some minor things that are inside the image that annoys me since some
>> > time.
>> >
>> > First issue: the tab morph we have is horrible (and makes horrible
>> > anything with it).
>> > I’ve been working on it to fix that “chromish-but-bad” style we had and
>> > to fix some (a lot) hardcoded colors there.
>> > Now, for example, Calypso looks like this:
>> >
>> >
>> >
>> >
>> > which is IMHO a lot better :)
>> >
>> > some remarks:
>> >
>> > 1) I find TabManagerMorph an ugly name. Do you think we should change
>> > it? (I tend to think anything called *Manager, *Controller, etc. as a
>> > bad naming chose and probably the mark of a smell).
>> > 2) much more important: we should deprecate TabGroupMorph and
>> > LazyTabGroupMorph family… there should not be more than one widget to do
>> > the same in the system.
>> >
>> > So well, as usual with old things: you fix a little thing and you
>> > uncover a lot of new problems :)
>> >
>> > Esteban
>> >
>> >
>>
>> Hi,
>>
>> I find those tabs too big. Am I the only one with this impression?
>>
>> But nice job, those are really better :)
>>
>> --
>> Cyril Ferlicot
>> https://ferlicot.fr
>>
>> http://www.synectique.eu
>> 2 rue Jacques Prévert 01,
>> 59650 Villeneuve d'ascq France
>>
>

Re: [Pharo-dev] [ann] moldable brick editor - alpha

[Esteban A. Maringolo]

It seems to be very snappy considering the size of the file and its amount
of characters.

I still don't get how Bloc and Brick plays in current Pharo, nor what this
"moldability" adds to it.
But performancewise it seems to be an improvement over the existing editor
(Rubric?).

Congratulations!




Esteban A. Maringolo

2017-08-05 7:52 GMT-03:00 Alexandre Bergel <alexandre.ber...@me.com>:

> This is gorgeous!
>
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
> > On Aug 4, 2017, at 6:19 PM, Tudor Girba <tu...@tudorgirba.com> wrote:
> >
> > Hi,
> >
> > We are very happy to announce the alpha version of a moldable editor
> built in Brick (https://github.com/pharo-graphics/Brick) which is based
> on Bloc (https://github.com/pharo-graphics/Bloc). This is primarily the
> work of Alex Syrel. The project was initially financially sponsored by ESUG
> and it is currently supported by feenk. And of course, the project is based
> on the tremendous work that went into Bloc and Brick by all contributors.
> >
> > Take a look at this 2 min video:
> > https://www.youtube.com/watch?v=2vy6VMJM9W4=youtu.be
> >
> > The basic editor works and it is both flexible and scalable. For
> example, the last example shown in the video is an editor opened on 1M
> characters, which is reasonably large, and as can be seen see one can
> interact with it as smoothly as with the one screen text. It actually works
> just as fine with 100M characters.
> >
> > The functionality of the editor includes: rendering, line wrapping,
> keypress and shortcut handling, navigation, selection and text styling.
> Currently, the editor is 1260  lines of code including method and class
> comments. This is not large for a text editor and this is possible because
> most of the work is done by generic concepts that already exist in Bloc
> such as layouts and text measurements. Beside the small maintenance cost,
> the benefit is that we have the option to build all sorts of variations
> with little effort. That is why we call this a moldable text editor.
> >
> > Another benefit of using elements and layouts is that we can also embed
> other kinds of non-text elements with little effort (such as pictures), and
> obtain a rich and live text editor. We already have basic examples for this
> behavior, and we will focus more in the next period on this area.
> >
> > The next immediate step is to add syntax highlighting. Beside the text
> attributes problem, this issue will also exercise the thread-safety the
> implementation is. The underlying structure (https://en.wikipedia.org/
> wiki/Rope_(data_structure)) is theoretically thread-safe, but it still
> needs to be proven in practice.
> >
> > We think this is a significant step because the editor was the main
> piece missing in Brick and it will finally allow us to build value that can
> be directly perceived by regular users on top of Brick and this, in turn,
> will generate more traction. Please also note that because now Bloc is
> directly embeddable in Morphic it means that we can actually start using it
> right away. For example, the picture below shows the text element being
> shown through a live preview in the GTInspector.
> >
> > 
> >
> > This is another puzzle piece towards the final goal of engineering the
> future of the Pharo user interface. There is still a long way to go to
> reach that goal, but considering the work that is behind us, that goal that
> looked so illusive when Alain and Stef initiated the Bloc project is now
> palpable.
> >
> > We will continue the work on this over the next period and we expect to
> announce new developments soon.
> >
> > If you want to play with it, you can load the code like this (works in
> both Pharo 6 and 7):
> > Iceberg enableMetacelloIntegration: true.
> > Metacello new
> >baseline: 'Brick';
> >repository: 'github://pharo-graphics/Brick/src';
> >load: #development
> >
> > Please let us know what you think.
> >
> > Cheers,
> > Alex and Doru
> >
> >
> >
> > --
> > www.tudorgirba.com
> > www.feenk.com
> >
> > "What is more important: To be happy, or to make happy?"
> >
>
>
>

Re: [Pharo-dev] [ANN] Mustache moved to github

[Esteban A. Maringolo]

Hi all

Sorry to Norbert for hijacking this post, but I'd also like to move
some of my projects to Github, I used Peter's scripts in the past, but
one thing I don't understand is how to automatically convert a
ConfigurationOf to a BaselineOf, and if this is really necessary.

Is the FileTree format, as used by filetree and gitfiletree MC repos,
100% compatible with the repository format of Iceberg? It seems so to
me, but it's better to ask than be sorry.

Regards!

Esteban A. Maringolo


2017-07-30 11:35 GMT-03:00 Peter Uhnak <i.uh...@gmail.com>:
>>
>> If I've understood correctly, this means you can rage master with a version 
>> number like v1.1 and then put that in the URL
>>
>> > https://github.com/peteruhnak/IconFactory/tree/master:v1.1/
>>
>
> I am not sure where you got this url from, but combining branch and tag name 
> makes nor sense... that's like you wanted a version 1.1 AND 2.3 (or whatever 
> would be the latest in master).
>
> (as mentioned in the syntax: branch name OR commit id OR tag id)
>
> Peter
>

Re: [Pharo-dev] [Ann] Keccak hashing algorithm

[Esteban A. Maringolo]

2017-07-18 17:33 GMT-03:00 Esteban A. Maringolo <emaring...@gmail.com>:
> 2017-07-18 17:26 GMT-03:00 Eliot Miranda <eliot.mira...@gmail.com>:
>> imply moving to github?  The Cryptography package has Squeak contributors
>> too and moving to github implies a fork.

> Last commit to Squeaksource repo is 4 years old.

I overlooked this, last commit is recent. My bad.

Re: [Pharo-dev] [Ann] Keccak hashing algorithm

[Esteban A. Maringolo]

2017-07-18 17:26 GMT-03:00 Eliot Miranda <eliot.mira...@gmail.com>:
> Norbert,
>
> On Tue, Jul 18, 2017 at 11:05 AM, Norbert Hartl <norb...@hartl.name> wrote:
>>
>> Really great! I think we should move the Cryptography package from
>> smalltalkhub to github, refactor it and add goodies like this. We need a
>> strong crypto foundation.
>
>
> I agree that refactoring and adding goodies is great.  But why does that
> imply moving to github?  The Cryptography package has Squeak contributors
> too and moving to github implies a fork.

The fork, soft or hard, already happened since Pharo incorporated in
"core" packages methods that belonged to the Cryptography package, so
loading this one overrides core methods.

Last commit to Squeaksource repo is 4 years old.


As per my last year announcement in
http://forum.world.st/Cryptography-packages-tp4915041p4915764.html

"I just adapted the latest version of the Cryptography package in
SqueakSource (Cryptography-rww.49) and removed everything that was
already in the Pharo 5.0 image and modified what was necessary to have
all the tests passing.

There is still a pending organization of the Cryptography classes and
packages per se, but this should be the reference implementation in
Pharo.

http://smalltalkhub.com/#!/~Cryptography/Cryptography/;

Regards,


Esteban A. Maringolo

Re: [Pharo-dev] [Ann] Keccak hashing algorithm

[Esteban A. Maringolo]

Great!

I see you continue doing Ethereum related stuff ;-)

Regards!
Esteban A. Maringolo


2017-07-18 13:32 GMT-03:00 Santiago Bragagnolo <santiagobragagn...@gmail.com>:
> Hi there!
>
> I am just releasing the first version of the Keccak-256 hashing algorithm.
> https://en.wikipedia.org/wiki/SHA-3
>
> You can find it at: https://github.com/sbragagnolo/Keccak
>
> This  version is based on a javascript implementation:
> https://github.com/emn178/js-sha3
>
> This implementation supports  as message: bytearray and ascii and utf-8
> strings.
>
>
> Soon i will be adding support to the rest of the Keccak family of hashing
> functions, since the implementations is quite configurable, is just need to
> add some constructors with specific configurations and tests for this other
> cases of usage.
>
>
> Here a onliner for building an image with the version v0.1:
>
>  wget -O- https://raw.githubusercontent.com/sbragagnolo/Keccak/v0.1/build.sh
> | bash
>
> Hope you find it useful :)
>
>
> Santiago
>
>

Re: [Pharo-dev] Reflecting on data (literal) object syntax

[Esteban A. Maringolo]

2017-06-30 8:28 GMT-03:00 Norbert Hartl :
>> Am 30.06.2017 um 12:03 schrieb Stephane Ducasse :

>> recently I started to read a book on machine learning and they
>> manipulate dictionary of dictionary. (So I started my own
>> implementation and I will switch to DataFrame).
>>
> having an abstract notation for a structure (or dictionary of dictionary) is 
> something really useful. I work a lot with JSON and the creation in pharo is 
> done the same way but you have to call asDictionary all the time which is 
> annoying. This can be rethought and would make things less ugly if we had a 
> good way. If it is close to S-expressions the better.

I don't what black magic requires, but having a syntax compatible with
JSON would be a HUGE boost.

Maybe because of where the keys are located on my keyboard layout, but
the #-> selector, although I understand its semantics, it's cumbersome
to type. I'd love a more compact representation.
If the compiler could be modified to accept $: as a message selector,
then we could map it to return an Association as #-> currently does. I
can't foresee the implications of such change.


> What I don't like about it is that the object literal exposes the internal 
> implementation of the object. Everything is based on index. So it could 
> suffer the same problem as fuel. When you don't have the exact same code the 
> deserialization fails. As a dictionary is both, an array of associations and 
> a key-value store, it works perfectly there. But for other objects I have 
> doubts. Especially is in a lot of contexts you need to have a mapping of 
> internal state to external representation. It can be applied afterwards but 
> I'm not sure that can work all the time.

One of the stregths of the JSON format is it doesn't matter in which
order the data arrives, otherwise you'd use a Array, because you
already know the indices of the data you're looking for.

Regards!

--
Esteban.

Re: [Pharo-dev] [ANN] P3, a modern, lean and mean PostgreSQL client for Pharo

[Esteban A. Maringolo]

Amazing work Sven!!!

This is very good.

Esteban A. Maringolo


2017-06-27 9:56 GMT-03:00 Sven Van Caekenberghe <s...@stfx.eu>:
> P3 is a modern, lean and mean PostgreSQL client for Pharo.
>
> P3Client uses frontend/backend protocol 3.0 (PostgreSQL version 7.4 [2003] 
> and later), implementing the simple query cycle. It supports plaintext and 
> md5 password authentication as well as SSL connections. When SQL queries 
> return row data, incoming data is efficiently converted to objects. P3Client 
> supports most common PostgreSQL types.
>
> With P3DatabaseDriver, an interface between Glorp, an advanced 
> object-relational mapper, and P3Client, most Glorp unit tests pass (the same 
> number as the older, proven PostgresV2 driver, that is using the legacy 2.0 
> protocol). This was the initial design goal.
>
> More info, usage examples and code at https://github.com/svenvc/P3
>
> P3 is written in pure Pharo, using a TCP network connection to PostgreSQL.
>
> This is an alpha release for the brave of heart that needs more real world 
> testing before it is ready for general release.
>
> Sven
>
> PS: I wrote this using 64-bit Pharo 6 on macOS using the Calypso browser and 
> it was a beautiful & satisfying experience. Thank you Denis, well done ! I 
> also used Iceberg a second time and it starts to feel natural to me. Thank 
> you Nico and Esteban !
>
>

Re: [Pharo-dev] [ Pillar ] Plumbing travis + github => pdf delivered to you

[Esteban A. Maringolo]

Excellent!

Thank you Damien!
Esteban A. Maringolo


2017-06-06 15:48 GMT-03:00 Stephane Ducasse <stepharo.s...@gmail.com>:
> Thanks Damien Pollet now we have a new pdf inside git hub each time you 
> commit.
>
> Here are two examples
> - https://github.com/SquareBracketAssociates/Booklet-Smacc/releases
> - https://github.com/SquareBracketAssociates/Booklet-Glorp/releases
>
> I'm going to do that for all the booklets and books :)
>
> Stef
>

Re: [Pharo-dev] New and richer halt messages

[Esteban A. Maringolo]

2017-06-04 6:40 GMT-03:00 Peter Uhnak <i.uh...@gmail.com>:
> On Sat, Jun 03, 2017 at 02:46:30PM -0700, Sean P. DeNigris wrote:
>> Henrik-Nergaard wrote
>> > Sounds like a good idea, but please implement them as constructors/class
>> > side methods in Halt instead of adding even more methods to Object.
>>
>> You're speaking my language! When Stephan Eggermont and I paired at ESUG
>> creating the Halt API, we wanted to remove all the Object methods, but we
>> were advised not to scare the users too much ha ha. Maybe the time has
>> finally come?!
>
> But then I wouldn't be able to write 1halt. :(


I'd only leave #halt in Object, anything else goes to Halt class.

I became a user of "1 halt" as well.


Esteban A. Maringolo

Re: [Pharo-dev] please test download for Pharo 6.0

[Esteban A. Maringolo]

I downloaded Windows (32 bit only). Played around and had no visible
issues so I ran the tests and got some errors and failures (I don't
know whether they're expected):

14425 run, 14342 passes, 29 skipped, 57 expected failures, 17
failures, 9 errors, 0 unexpected passes
Failures:
MCSnapshotBrowserTest>>#testNoSelection
MCWorkingCopyTest>>#testSimpleMerge
MCStWriterTest>>#testInitializerDefinition
MetacelloRepositorySqueakCommonTestCase>>#testDirectoryRepository
MetacelloRepositorySqueakCommonTestCase>>#testAsRepositorySpecFor
MCSnapshotTest>>#testCreation
MCWorkingCopyTest>>#testOptimizedLoad
MCSnapshotBrowserTest>>#testClassSelected
ReleaseTest>>#testMethodsWithUnboundGlobals
MCSnapshotBrowserTest>>#testCategorySelected
MCWorkingCopyTest>>#testRepeatedMerge
MCSnapshotBrowserTest>>#testClassSideClassSelected
MCPatchTest>>#testPatchContents
ZnClientTests>>#testIfFailNotFound
MCWorkingCopyTest>>#testSelectiveBackport
MCWorkingCopyTest>>#testSnapshotAndLoad
GLMRubricTextMorphicTest>>#testPastingUpdatesTextPort

Errors:
MCPackageTest>>#testUnloadWithAdditionalTracking
MCSnapshotBrowserTest>>#testMethodIsCleared
MCSnapshotBrowserTest>>#testMethodSelected
MCSnapshotBrowserTest>>#testProtocolIsCleared
MCSnapshotBrowserTest>>#testProtocolSelected
MCStWriterTest>>#testClassMethodDefinition
MCStWriterTest>>#testMethodDefinition
MCWorkingCopyTest>>#testBackport
MCFileInTest>>#testStWriter



Best regards!
Esteban A. Maringolo


2017-05-31 13:39 GMT-03:00 Esteban Lorenzano <esteba...@gmail.com>:
> But I tested Roassal (and Athens) in 64bits and they were working.
> What changed?
>
> On 31 May 2017, at 18:33, Alexandre Bergel <alexandre.ber...@me.com> wrote:
>
> Hi Volkert,
>
> Roassal does not work on Pharo 64-bits. The issue here is Athens.
>
> When Pharo 6 will be released, we will evaluate the options to make Roassal
> run on 64 bits. The option I see, is using Pompeii, the backend by Ronie
> that uses directly OpenGL. This works well on Pharo 64 bits.
>
> Someone see another option?
>
> Cheers,
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
> On May 31, 2017, at 12:24 PM, volkert <volk...@nivoba.de> wrote:
>
> Downloaded Linux 64 Bit.
> Installed Roassal.
> Run Examples.
> VM crashed :-(
>
> BW, Volkert
>
> Am 31.05.2017 um 17:59 schrieb Esteban Lorenzano:
>
> On 31 May 2017, at 17:46, Peter Uhnak <i.uh...@gmail.com> wrote:
>
> I find the Windows distribution a bit chaotic as all the files (vm, vm libs,
> image, sources) are in the same folder. Maybe there were issues with using
> shortcuts? Because then launching the image will also create pharo-local in
> the folder (and any other file that image writes to imageDirectory), so it
> could be more chaos for a new user.
>
> yes, it has been like that since some time and we need to change it… but not
> now for release :)
>
> The linux distro contains sources twice
> 1) pharo6.0/shared/PharoV60.sources
> 2) pharo6.0/bin/PharoV60.sources
>
> yeah, that’s also a problem from one-click days… maybe I can fix that/
>
> Esteban
>
> Peter
>
>
> On Wed, May 31, 2017 at 04:18:19PM +0200, Esteban Lorenzano wrote:
>
> Hello,
>
> we are getting ready for release.
> please take a minute to review:
>
> http://pharo.org/STAGE.download <http://pharo.org/STAGE.download>
>
> (notice that zerconf download will not work because it is not yet moved… so
> #stable will download current stable version which is 5.0)
>
> cheers,
> Esteban
>
>
>

Re: [Pharo-dev] Chrome DevTools Protocol and Pharo

[Esteban A. Maringolo]

This is really cool!

Thank you for doing it!

El may. 18, 2017 4:21 PM, "Torsten Bergmann"  escribió:

> Hi,
>
> I played around with remote controlling Google Chrome from
> Pharo using Chrome DevTools Protocol [1] (based on WebSockets).
>
> The video shows an example using latest Pharo 6 on Mac:
> https://www.youtube.com/watch?v=9F5FrQTEJWY
>
> Initial Code is on GitHub [2] if someone is interested,
> requires OSOSX and Zinc Websockets to be loaded.
>
> Have fun
> T.
>
> [1] https://chromedevtools.github.io/devtools-protocol
> [2] https://github.com/astares/Pharo-Chrome
>
>

Re: [Pharo-dev] Missing plugins to make the vmProfiler work on Pharo

[Esteban A. Maringolo]

2017-05-10 13:38 GMT-03:00 Clément Bera <bera.clem...@gmail.com>:
> On Wed, May 10, 2017 at 5:28 PM, Esteban A. Maringolo <emaring...@gmail.com> 
> wrote:

>> If it is a plug-in, why does it need VM recompilation?
>
> Internal plugins require VM recompilation. Only external plugins do not.

It was more of a semantic question, I'd expect a plug-in to be that,
pluggable, as you say external plugins are.
Or what is the "pluggability" of such plugins?

Disclaimer: I don't know about the VM internals (*), and this is not a
complain of any sort. I just wonder it is called that way.

Regards!

Esteban A. Maringolo

(*) I did compile a Squeak VM a decade ago (added two primitives) but
nothing more than that.

Re: [Pharo-dev] Missing plugins to make the vmProfiler work on Pharo

[Esteban A. Maringolo]

If it is a plug-in, why does it need VM recompilation?

Esteban A. Maringolo






2017-05-10 12:15 GMT-03:00 Nicolas Cellier <nicolas.cellier.aka.n...@gmail.com>:
> Hi Sophie,
> you could try and modify the plugins.int or plugins.ext files for various
> pharo distributions and do a pull request on github opensmalltalk-vm.
> Then let Esteban accept the request or not before the release of Pharo...
> (if the build are green, there's no reason to not accept it).
>
> 2017-05-10 15:39 GMT+02:00 Max Leske <maxle...@gmail.com>:
>>
>> OK, I see.
>>
>>
>> On 10 May 2017, at 15:11, Clément Bera <bera.clem...@gmail.com> wrote:
>>
>> Hi Max,
>>
>> She has already done that. The point is to add the plugins in the default
>> Pharo VM, so everyone can use the VM profiler. We would like to have the VM
>> profiler loadable through the Pharo catalog, but many people won't be able
>> to use it if the default Pharo VM does not support it...
>>
>> The plugin is lightweight, so I don't see why we can't have it.
>>
>> Best,
>>
>> On Wed, May 10, 2017 at 3:00 PM, Max Leske <maxle...@gmail.com> wrote:
>>>
>>> Hi Sophie,
>>>
>>> You will have to compile your own VM for the moment. It's fairly easy but
>>> you might run into problems when including the extra plugin. To build the
>>> VM, follow the instructions on
>>> https://github.com/OpenSmalltalk/opensmalltalk-vm and read the README and
>>> HOWTO files. Simple build example:
>>>
>>> cd ~/git/opensmalltalk-vm/build.macos32x86/pharo.cog.spur/ && ./mvm -d
>>>
>>> will build a debug VM. You'll have to modify one of the "plugins.*" files
>>> to include the plugin.
>>>
>>> HTH,
>>> Max
>>>
>>> On 10 May 2017, at 14:36, Sophie Kaleba <sophie.kal...@gmail.com> wrote:
>>>
>>> Hi Esteban, Hi all,
>>>
>>> I am working on porting the Squeak VMProfiler to Pharo as a gsoc (I will
>>> post a more detailed presentation about that in the mailing list later
>>> today).
>>>
>>> While trying to use the profiler with the Pharo VM, I get the following
>>> error : "PrimitiveFailed : primitive #primitiveExecutableModules in
>>> VMProfilerLinuxSymbolsManager failed". (see stack trace attached).
>>>
>>> This plugin (VMProfileLinuxSupportPlugin) does not seem to be included by
>>> default in the Pharo VM (it works with a Squeak VM). I haven't tried on a
>>> mac, but I guess the plugin (VMProfileMacSupportPlugin) is missing too.
>>>
>>> For the moment, I am using the latest Squeak VM with my Pharo image but
>>> it is not quite convenient. Would it be possible to include the 2 plugins to
>>> the Pharo VM ?
>>>
>>> If I can be of any help, just tell me
>>> Thanks!
>>>
>>> Sophie
>>>
>>>
>>>
>>>
>>>
>>>
>>> 
>>>
>>>
>>
>>
>

Re: [Pharo-dev] Pharo booklet collection

[Esteban A. Maringolo]

Correct link seems to be

http://files.pharo.org/books-pdfs/booklet-Glorp/2017-05-02-Glorp.spiral.pdf
Esteban A. Maringolo


2017-05-02 17:28 GMT-03:00 p...@highoctane.be <p...@highoctane.be>:
> link for glorp gives smacc book error
>
> On Tue, May 2, 2017 at 10:25 PM, Stephane Ducasse <stepharo.s...@gmail.com>
> wrote:
>>
>> Hi Pharoers
>>
>> You are lucky. The "Pharo booklet collection" edited by S. Ducasse is
>> arriving...
>>
>> Are you ready to read nice and focused booklets?
>>
>> You can find at http://files.pharo.org/books/ in beta version:
>>
>> Smacc: the Smalltalk Compiler Compiler by J. Brant, T. Goubier, J. Lecerf
>> and S. Ducasse.
>> Glorp: the Object Relational Mapper framework by E. Maringolo, N. Pratt
>> and R. Withney
>>
>> All the book material is hosted on
>> https://github.com/SquareBracketAssociates so you can contribute! Fix typos
>> and propose new material.
>>
>> We are planning a booklet on Magritte, Reddit in 10 cool classes, Voyage,
>> and Mocking with BabyMock and Mocketry, XML (but we need a writer) and
>> potentially PetitParser.
>>
>> If you have material for a tutorial and you would like to be part of the
>> Pharo Booklet Collection contact S. Ducasse.
>>
>> S. Ducasse
>
>

Re: [Pharo-dev] GarageGlorp

[Esteban A. Maringolo]

It is done.

Regards!
Esteban A. Maringolo


2017-04-30 14:32 GMT-03:00 Stephane Ducasse <stepharo.s...@gmail.com>:
> tx
>
> On Sun, Apr 30, 2017 at 5:36 PM, Esteban A. Maringolo <emaring...@gmail.com>
> wrote:
>>
>> I will do so as soon as I sit in front of my computer.
>>
>> Regards!
>>
>> El abr. 29, 2017 3:35 PM, "Stephane Ducasse" <stepharo.s...@gmail.com>
>> escribió:
>>>
>>> Hi
>>>
>>> for a tutorial I wanted to load Glorp in Pharo 60 as described in the
>>> Glorp doc.
>>>
>>> Metacello new
>>> smalltalkhubUser: 'DBXTalk' project: 'Garage';
>>> configuration: 'GarageGlorp';
>>> version: #stable;
>>> load.
>>>
>>> I get an error stating that
>>> The symbolic version stable is not defined in the configuration for the
>>> ... for the platform.
>>>
>>> I changed the loading instruction to
>>>
>>> Metacello new
>>> smalltalkhubUser: 'DBXTalk' project: 'Garage';
>>> configuration: 'GarageGlorp';
>>> version: '0.2';
>>> load.
>>>
>>> And it seems to work. May be we should publish a symbolic version for
>>> pharo 60.
>>> I do not think that I have commit right.
>>>
>>> Stef
>
>

Re: [Pharo-dev] GarageGlorp

[Esteban A. Maringolo]

I will do so as soon as I sit in front of my computer.

Regards!

El abr. 29, 2017 3:35 PM, "Stephane Ducasse" 
escribió:

> Hi
>
> for a tutorial I wanted to load Glorp in Pharo 60 as described in the
> Glorp doc.
>
> Metacello new
> smalltalkhubUser: 'DBXTalk' project: 'Garage';
> configuration: 'GarageGlorp';
> version: #stable;
> load.
>
> I get an error stating that
> The symbolic version stable is not defined in the configuration for the
> ... for the platform.
>
> I changed the loading instruction to
>
> Metacello new
> smalltalkhubUser: 'DBXTalk' project: 'Garage';
> configuration: 'GarageGlorp';
> version: '0.2';
> load.
>
> And it seems to work. May be we should publish a symbolic version for
> pharo 60.
> I do not think that I have commit right.
>
> Stef
>

Re: [Pharo-dev] Pharo 6 screenshot

[Esteban A. Maringolo]

Awesome, literally, as in awe. It will be hard to measure, but I'd bet
that screenshot would bring more people to Pharo tan many blog posts
and other efforts. A picture is worth a thousand words.

Great work!

Esteban A. Maringolo


2017-04-24 18:48 GMT-03:00 Pavel Krivanek <pavel.kriva...@gmail.com>:
> Right, next try...
>
> https://goo.gl/photos/YnGoZTrpKjJnSbFU9
>
> -- Pavel
>
>
>
> 2017-04-24 22:22 GMT+02:00 Cyril Ferlicot D. <cyril.ferli...@gmail.com>:
>>
>> Le 24/04/2017 à 22:13, Pavel Krivanek a écrit :
>> > New version:
>> >
>> > https://goo.gl/photos/66Yz3pSSK62aTYV66
>> >
>> > -- Pavel
>> >
>>
>> Pretty nice but too blurry for me. Especially on the right of the screen.
>>
>> But maybe it's just me.
>>
>> --
>> Cyril Ferlicot
>> https://ferlicot.fr
>>
>> http://www.synectique.eu
>> 2 rue Jacques Prévert 01,
>> 59650 Villeneuve d'ascq France
>>
>

Re: [Pharo-dev] Pharo 6 screenshot

[Esteban A. Maringolo]

I like the focus of the first with the windows of the second. It is...
less blur in the new version or a sharper focus area at least.

Anyway I love it. :)
Esteban A. Maringolo


2017-04-24 17:13 GMT-03:00 Pavel Krivanek <pavel.kriva...@gmail.com>:
> New version:
>
> https://goo.gl/photos/66Yz3pSSK62aTYV66
>
> -- Pavel
>
> 2017-04-24 10:36 GMT+02:00 Tudor Girba <tu...@tudorgirba.com>:
>>
>> The problem is that we need a proper Roassal integration without the white
>> background :). Otherwise it looks not so nice.
>>
>> Doru
>>
>>
>> > On Apr 24, 2017, at 10:14 AM, p...@highoctane.be wrote:
>> >
>> > Nice, I'd put some more Roassal things, like Sunburst
>> >
>> >
>> > On Mon, Apr 24, 2017 at 9:14 AM, Sven Van Caekenberghe <s...@stfx.eu>
>> > wrote:
>> > I like it !
>> >
>> > > On 24 Apr 2017, at 08:58, Pavel Krivanek <pavel.kriva...@gmail.com>
>> > > wrote:
>> > >
>> > > Hi,
>> > >
>> > > I tried to prepare some "geeky" screenshot for Pharo 6 announcements
>> > > and advertisements.
>> > >
>> > > https://goo.gl/photos/NF5EC6dCinXRWosA9
>> > >
>> > > -- Pavel
>> >
>> >
>> >
>>
>> --
>> www.tudorgirba.com
>> www.feenk.com
>>
>> “Software has no shape. Actually, it has no one shape. It has many."
>>
>>
>

Re: [Pharo-dev] In the quest of a new iterator :)

[Esteban A. Maringolo]

2017-04-20 13:31 GMT-03:00 Nicolas Cellier <nicolas.cellier.aka.n...@gmail.com>:
>
>
> 2017-04-20 17:06 GMT+02:00 Ben Coman <b...@openinworld.com>:

> On the other hand, we have #keysAndValuesDo: which competes with
> #withIndexDo: and is a bit more portable across dialects
> (it's just that it turns the bloc parameters the other way around, [:index
> :element | ])
>
> So maybe this should have been #keysAndValuesSelect: #keysAndValuesCollect:

+1

> Reminder, keys does not mean Dictionary, in an IndexedCollection (or maybe a
> SequenceableCollection) the keys are indices. Or the other way around, a
> Dictionary is indexed by arbitrary keys (not just positive integers).

This is what I was trying to explain at the beginning. :)


Esteban A. Maringolo

Re: [Pharo-dev] In the quest of a new iterator :)

[Esteban A. Maringolo]

2017-04-19 16:17 GMT-03:00 Stephane Ducasse <stepharo.s...@gmail.com>:
> why?
> Iterators are powerful and avoid that we all reinvent the wheel in our own
> corners.
>
> About keySelect: I do not see the point to convert a large collection into a
> dictionary then do yet another pass.
> To me it looks like a hack.

keySelect: would do a select based on the key (index in the case of
SequenceableCollection) of the element, no need to create a
Dictionary.

keySelect: aBlock
  | result |
  result := self species new.
  self keysAndValuesDo: [:key :value |
 (aBlock value: key) ifTrue: [result add: value]
  ].
  ^result


You could implement #selectEverySecond or #selectEveryFirst in terms
of the above. The name sounds weird though, but I'm not a native
English speaker.

Regarding #unzip it's a different story, I wouldn't use 'zip' in a
selector for non Zip (compression) related methods.

But do as you please, Pharo is yours as well ;)

Regards!


> I implemented
> selectEvery:
> (selectFirst selectSecond) as helpers.
>
> and also unzip all in one pass.
> Now I have no problem to keep them for me but to me this is the wrong
> attitude.
>
> Stef
>
>
> testSelectEveryFirst
> self assert: (#(#Object #subclass: #Point #instanceVariableNames: 'x y'
> #classVariableNames: '' #package: 'Kernel-BasicObjects') selectEveryFirst)
> asArray equals: #(#Object #Point 'x y'  '' 'Kernel-BasicObjects')
> testSelectEverySecond self assert: (#(#Object #subclass: #Point
> #instanceVariableNames: 'x y' #classVariableNames: '' #package:
> 'Kernel-BasicObjects') selectEverySecond) asArray equals: #(#subclass:
> #instanceVariableNames: #classVariableNames: #package:)
> testUnzip
> | uz |
> uz := #(#Object #subclass: #Point #instanceVariableNames: 'x y'
> #classVariableNames: '' #package: 'Kernel-BasicObjects') unzip.
> self assert: uz first asArray equals: #(#Object #Point 'x y'  ''
> 'Kernel-BasicObjects').
> self assert: uz second asArray equals: #(#subclass: #instanceVariableNames:
> #classVariableNames: #package:)


Esteban A. Maringolo

Re: [Pharo-dev] In the quest of a new iterator :)

[Esteban A. Maringolo]

2017-04-19 15:43 GMT-03:00 Stephane Ducasse :
> Hi
>
> I have
>
>  #(#Object #subclass: #Point #instanceVariableNames: 'x y'
> #classVariableNames: '' #package: 'Kernel-BasicObjects') and I would like to
> select on the second elements.
>
> I was thinking that
>
>  #(#Object #subclass: #Point #instanceVariableNames: 'x y'
> #classVariableNames: '' #package: 'Kernel-BasicObjects') selectEvery: [ :i |
> i \\ 2 = 0 ]
> could be a nice iterator.
>
> What do you think?

I think I wouldn't add a new enumerating selector to the core classes.

If it needs to be there, I would replace it by #keysSelect:

So it would work to select based on the keys of the receiver (indexes
for sequenced collections) but also would work as it does for
#keysAndValuesDo: implementors.

Regards,


--
Esteban.

Re: [Pharo-dev] [Ann] Commander. Command pattern library

[Esteban A. Maringolo]

Nice work, I like the approach.

Did you inspire your work in how Dolphin and VAST implements menu
creation, command execution, and so on?
I find your solution similar to how Dolphin implements it, where even
each Presenter is even queried about each command by using a command
query and routing solution.

Will you use this in the context of Calypso and friends?

Regards!


Esteban A. Maringolo


2017-04-11 11:49 GMT-03:00 Denis Kudriashov <dionisi...@gmail.com>:
> Hi.
>
> I am glad to announce Commander library which implements command pattern
> based on first class objects.
> In Commander every application action is implemented as separate class with
> #execute method and all state required for execution.
>
> Commands are reusable objects and applications provide various ways to
> access them: shortcuts, context menu, buttons, etc.. This information is
> attached to command classes as activator objects. Currently there are three
> types of activators:
>
> - CmdShortcutCommandActivator
> - CmdContextMenuCommandActivator
> - CmdDragAndDropCommandActivator
>
> Activators are declared in command class side methods marked with pragma
> #commandActivator. For example following method will allow
> RenamePackageCommand to be executed by shortcut in possible system browser:
>
> RenamePackageCommand class>>packageBrowserShortcutActivator
>
>   
>   ^CmdShortcutCommandActivator by: $r meta for: PackageBrowserContext
>
>
> And for context menu it will be:
>
>
> RenamePackageCommand class>>packageBrowserMenuActivator
>
>^CmdContextMenuCommandActivator byRootGroupItemFor:
> PackageBrowserContext
>
>
> Activators are always declared with application context where they can be
> applied (PackageBrowserContext in example). Application should provide such
> contexts with information about application state. Every widget can bring
> own context to interact with application as separate tool. For example
> system browser shows multiple panes which provide package context, class
> context and method context. And depending on context browser shows different
> menu and provides different shortcuts.
>
> For more details look at my blog
> http://dionisiydk.blogspot.fr/2017/04/commander-command-pattern-library.html
> and read docs here.
>
> Best regards,
> Denis
>
>

Re: [Pharo-dev] Tired of losing messages after 10k. Can we re-discuss moving Slack community to Discord?

[Esteban A. Maringolo]

We could shut down Slack team or leave a sticky note in the general
channel saying that we moved everything to Discord.

Regards!


Esteban A. Maringolo


2017-04-07 9:39 GMT-03:00 Alexandre Bergel <alexandre.ber...@me.com>:
> I would not mind moving to Discord. But, what is the plan to kill Slack? Can
> a Slack project be simply removed?
>
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
> On Apr 7, 2017, at 8:59 AM, Esteban Lorenzano <esteba...@gmail.com> wrote:
>
> Hi,
>
> That.
> I’m also willing to try another service if you find something better, but I
> find discord cool enough.
> Some remarks:
>
> - I actually like Slack. The problem is the amount of information lost
> because they do not display more than 10k lines (or we pay, and is super
> expensive).
> - No, plain #irc is not an option. Community has talked… and it does not
> works… I have had more productive talks in one month in Slack than 5 years
> trying #irc.
>
> cheers!
> Esteban
>
>
>

Re: [Pharo-dev] [ANN] threaded heartbeat VMs added to zeroconf

[Esteban A. Maringolo]

Can you explain what a Threaded Heartbeat VM is?
I can do some inference based on the name, but I'll probably be wrong.

Regards!
Esteban A. Maringolo


2017-03-13 14:38 GMT-03:00 Esteban Lorenzano <esteba...@gmail.com>:
> Hello,
>
> Following recent talks, I added threaded heartbeats VMs to zeroconf.
> Is weird because is not anymore “zero” conf: you need to configure the
> machine to accept this VM… but well, this is like that :P
>
> The links to use are this:
>
> http://get.pharo.org/vmT60
> http://get.pharo.org/vmTLatest60
> http://get.pharo.org/alpha+vmT
> http://get.pharo.org/alpha+vmTLatest
> http://get.pharo.org/60+vmTLatest
>
> (they are listed at http://get.pharo.org, as usual)
>
> cheers,
> Esteban
>

Re: [Pharo-dev] [ANN] Fog - Ethereum driver

[Esteban A. Maringolo]

Very Nice! Thank you for building it.

I started a similar project for the Bitcoin blockchain, but then I
drifted away and never got back to it.

Are you writing DAPPs?

Best regards,

Esteban A. Maringolo


2017-03-13 12:00 GMT-03:00 Santiago Bragagnolo <santiagobragagn...@gmail.com>:
> Hi all. Im happy to announce a pre release of the Fog ethereum driver that
> we develop in the space of an Inria project.
>
> It still not complete but is already usable for some experiments and simple
> projects.
>
> You can downloadit from
> https://github.com/sbragagnolo/Fog/
> (https://github.com/sbragagnolo/Fog/releases/tag/v0.1.1.1)
>
> Dependencies
>
> RHash
>
>  sudo apt-get install rhash
>
> Solidity
>
>  npm install solc
>
> Download code
>
> Iceberg / Baseline
>
> Metacello
> new
> baseline: 'Fog';
> repository:  'github://sbragagnolo/Fog:v0.1.1.1/src';
> load.
>
> By hand
>
> You may want to use this version for having access to some scripts and
> contracts samples.
>
> git checkout g...@github.com:sbragagnolo/Fog.git
>
> git checkout v0.1.1.1
>
> Metacello
> new
> baseline: 'Fog';
> repository: 'filetree:///path/to/git-repository/Fog/src';;
> load.
>
>
> It's based on the standar API for javascript
> (https://github.com/ethereum/wiki/wiki/JavaScript-API) .
>
> It provides interaction with remote contracts, it do as well provides a way
> for navigating the architecture objects: blocks, transactions, accounts and
> contracts.
>
> I hope you find it useful.
>
> Feel free to fill the github issue tracker with anything you find :).
>
>
> I will come to you with some new exciting news about ethereum soon :)
>
> Santiago.
>
>
>
>
>
>

Re: [Pharo-dev] Any idea for a cool name for the remote tool suite?

[Esteban A. Maringolo]

If anybody ever did an `apt-cache search name` it will be clear that
having a good, concise, intention revealing package name is better
than having a sophisticated one. I don't see how in Pharo catalogs and
other discovery/browsing mechanisms it would be different.

Best regards!

Esteban A. Maringolo


2017-02-24 7:34 GMT-03:00 Markus Fritsche <mfrits...@reauktion.de>:
> Hello,
>
> I guess the vote is already cast, but I'd like to add my two Cents:
>
> the packages now have a description that give an idea about what the package
> is supposed to do. Still, discoverability should be considered when finding
> a name. That's why I would prefer something like TelePharo, since the name
> already hints at the core functionality.
>
> Best regards,
>   Markus
>
>
> Am 29.01.2017 15:14, schrieb stepharong:
>>
>> Hi guys
>>
>> Since we will push the remote tools (videos/web...) I would like to
>> get  some ideas for a cool name.
>> Any ideas?
>>
>> Because Pharmide (looks like medicine or chemical product).
>> Since I vaguely remember some german Pharmide made me think about
>> Fern(sehen) but this is not a good name.
>>
>> Stef
>>
>>
>> --
>
>

Re: [Pharo-dev] Slack, fragmentation and design information

[Esteban A. Maringolo]

2017-02-10 21:09 GMT-03:00 Dimitris Chloupis <kilon.al...@gmail.com>:

> On Sat, Feb 11, 2017 at 1:52 AM p...@highoctane.be <p...@highoctane.be>
> wrote:
>>
>> Am still finding useful stuff on Squeak wiki, sorry.
>> The point of a Wiki is to capture discussions over a given topic and make
>> it grow into something more structured over time. Like original c2 wiki.

> I fail to see the problem here


It's not a problem, it's a dynamics thing. GitHub isn't the same, I
haven't seen big wikis hosted there for a long time. In the long run
Pareto appears, and only a fraction of the users create most of the
content, but it is still useful.

In my previous job we used Squeak's Swiki for years and then we
migrated it to Atlassian's Confluence (due to better user support),
and it is amazing how powerful and undervalued a wiki is.

If haven't used the c2 wiki or the squeak wiki then you haven't
experienced what it meant, at that time, to find everything there, or
expand articles with your own content. It was really useful, c2 still
is.

Wiki's value is like compound interest, you only perceive the benefits
in the mid to long term.

Regards,


Esteban A. Maringolo

Re: [Pharo-dev] Slack, fragmentation and design information

[Esteban A. Maringolo]

2017-02-10 14:59 GMT-03:00 p...@highoctane.be <p...@highoctane.be>:
> Mass adoption and hyper reduced friction to get people on board.
>
> For me: I have 10+ slack teams in my slack client and there is really no
> point in having more clients on the desktop.

+1 to this. This is key.

Maybe what we're missing is a simple wiki to collect the shared
knowledge, recipes, and other stuff.


Esteban A. Maringolo

Re: [Pharo-dev] Any idea for a cool name for the remote tool suite?

[Esteban A. Maringolo]

+1 to simple names.

Pharo Remote.
No accronym involved, no lookup to know what it means.

A remote it also a noun, i.e. something you use to control your TV remotely :D

If you want more details... Pharo Remote Toolkit.
Tools is too abstract, toolkit is a set of tools meant to work
together o a particular kind of task..


Best regards,

Esteban A. Maringolo


2017-01-30 12:08 GMT-03:00 Volkert <volk...@nivoba.de>:
> +100
>
>
> On 30.01.2017 15:31, Brad Selfridge wrote:
>
> I'm not a big fan of cryptic names. I already think there are way too many
> in Pharo. You look at the names and have no idea what they do. Why not call
> it what it is: "Pharo Remote IDE" or "RemoteIDE".  It's simple and it tells
> the user EXACTLY what it is without digging into some obscure document, (or
> no document at all).
>
>
> --
> Brad Selfridge
> bsselfri...@gmail.com
>
>
>
> On 01/30/2017 08:25 AM, Denis Kudriashov wrote:
>
>
> 2017-01-30 14:21 GMT+01:00 Ben Coman <b...@openinworld.com>:
>>
>> btw, what is the "m" for in PharmIDE ?
>
>
> First it is like farm.
> Seconds it is Pharo Remote IDE
>
>
>

Re: [Pharo-dev] Pragma keyword / selector / methodSelector

[Esteban A. Maringolo]

2016-11-14 11:50 GMT-03:00 Denis Kudriashov <dionisi...@gmail.com>:
>
> 2016-11-14 15:37 GMT+01:00 Esteban A. Maringolo <emaring...@gmail.com>:
>>
>> Breaking Metacello in any version = Not good.
>>
>> Metacello is very backward compatible but breaking pragma semantics
>> would require a rewrite of many configurations that work okay today

> Why? ConfigurationOf~ not collect any pragmas by themselves. They only
> declare versions by pragmas.

You're right.

> And we only need to fix Pharo version of Metacello which is already fork.

Which is not there yet.

Quoting myself: "... and would require a new version of Metacello that
contemplates the new
selectors based on some criteria."

Criteria being pharo version, or anything else that identifies the new
pragma semantics.

Regards!

Re: [Pharo-dev] Pragma keyword / selector / methodSelector

[Esteban A. Maringolo]

2016-11-14 11:27 GMT-03:00 p...@highoctane.be <p...@highoctane.be>:
> Breaking Metacello in Pharo 6: Not good. Revert: +1

Breaking Metacello in any version = Not good.

Metacello is very backward compatible but breaking pragma semantics
would require a rewrite of many configurations that work okay today
and would require a new version of Metacello that contemplates the new
selectors based on some criteria.

Regards!

Esteban A. Maringolo

Re: [Pharo-dev] [ANN] Pharo Association has a new Website!

[Esteban A. Maringolo]

Great!

What do we do with the current BountySource salt?
(https://salt.bountysource.com/teams/pharo)
Should we move directly to the new Wild Apricot backend?

Accepting Bitcoin payments would be a plus ;-) (https://bitpay.com/tour)

Best regards!

Esteban A. Maringolo


2016-11-10 6:22 GMT-03:00 Marcus Denker <marcus.den...@inria.fr>:
> Hello,
>
> We have changed the backend of the Pharo Association.
>
> https://association.pharo.org
>
> If you ever joined the association in the past, please consider to
> re-subscribe.
>
> We have added already all existing active members, in this case you should
> have already received a new password.
>
> For all questions, do not hesitate to contact assocat...@pharo.org
>
>
> Marcus

Re: [Pharo-dev] Mocks are missing in Pharo (from thread OSProcess is missing)

[Esteban A. Maringolo]

2016-10-28 16:07 GMT-03:00 Guillermo Polito :
> On Fri, Oct 28, 2016 at 8:36 PM, Denis Kudriashov 
> wrote:

>> And there is another story. Imaging Ruby guys join Pharo development (not
>> real story :)). Many years In Ruby people use mocks and "human should"
>> assertions.

> Ruby guys can load the library they prefer. And use it in their projects.
> I'm no-one to forbid that, and actually I'd encourage it if that is what
> they want.
>
> And actually this is what they do in Ruby: if they want a library they load
> it. Why in Pharo it cannot be the same for god's sake??

+1 to this. We should be able to deliver a minimal core, with the
basic features to load external packages.

The problem, I suspect, is that project discoverability/installation
might not be as straightforward as with a ruby gem, but  the
integrated catalog eases that in a big extent.

Regards!

--
Esteban.

Re: [Pharo-dev] Pharo behind ALLSTOCKER marketplace

[Esteban A. Maringolo]

Thank you for sharing all your experience.
I wasn't aware of many of the packages you're using. And I like the
Mustaside approach for certain parts of a Seaside app.

It still surprises me how these packages can fly so low under the radar.

What version of Glorp are you using?


Best regards!

Esteban A. Maringolo

Re: [Pharo-dev] [JOB][Research] [Pre-Ann] Postdoc BlockChain

[Esteban A. Maringolo]

Not to post myself to this postdoc (I don't have a doctorate to start
with...) but I encourage anybody to embrace this.

I'm a Bitcoin user since two years, and since a year or so I'm getting into
Bitcoin and learning about Blockchain related technologies, it's
fascinating, and since I discovered Smalltalk ~15 years ago I haven't felt
so excited about a "new" technology" like this. In fact this this year I
won't be attending Smalltalks 2016 and instead I'll go to the LaBITConf (
http://www.labitconf.com/).

Related with the post I can say the number of Blockchain/Bitcoin academic
papers published every year is growing really fast.
https://docs.google.com/spreadsheets/d/1VaWhbAj7hWNdiE73P-W-wrl5a0WNgzjofmZXe0Rh5sg/edit#gid=0

Regards,


Esteban A. Maringolo

2016-09-23 10:53 GMT-03:00 Marcus Denker <marcus.den...@inria.fr>:

> Hi,
>
> Together with a local startup we are looking to fill a position for
> a 2 year postdoc for software engineering/tools/languages
> in the context of “BlockChain” technologies.
>
> A more detailed job call will be published soon, but if you are interested
> (or know someone), do not hesitate to contact me.
>
> Marcus
>

Re: [Pharo-dev] Call for design for a literal programming doc similar to PythonDocTest

[Esteban A. Maringolo]

2016-09-15 17:09 GMT-03:00 Tudor Girba <tu...@tudorgirba.com>:
> However, one thing to keep in mind is that one reason why these solutions 
> exist is because they assume no UI environment. Thus, the only thing they 
> have is text and the solution is built around it.
>
> In Pharo, we can think of concatenating information in the environment. If we 
> have a casual connection between examples and the code they exemplify, the 
> interface can provide all this information at the same time. The advantage 
> here is that the syntax remains simple.

+1

I wouldn't like that syntax, nor PharoDoc (a la JavaDoc), nor anything
"polluting" the code that way.

The comment or examples can be attributes of the method itself, just
like the class comment are today.

Regards!

Esteban A. Maringolo

Re: [Pharo-dev] why is gt playground not saving the code

[Esteban A. Maringolo]

2016-08-31 18:43 GMT-03:00 Tudor Girba <tu...@tudorgirba.com>:
> Hi,
>
>> On Aug 31, 2016, at 11:39 PM, Esteban A. Maringolo <emaring...@gmail.com> 
>> wrote:
>>
>> One use case that sometimes bites me is when I'm working in the "code"
>> of the Playground (first screen), and then I start going deep with
>> "Evaluate and Go", basically inspecting my objects, and then I close
>> the window thinking I'm dealing with an inspector hence losing the
>> code of the "workspace" in the Playground that started the inspection
>> "workflow", without receiving any warning about "losing" my changes.
>> I'd like an explicit "Save" in the Playground, but since I'm not
>> adding it, I can't complain much. :)
>
> Thanks for the input. What would the Save do in this case?

It should let me decide IF and WHEN to store the code contents.

Also, if you tests scripts in a workspace and evaluate them
"outside" of it (e.g. from the command line) I have to copy/paste the
contents back and forth from the Playground to a text editor to
save/modify something that in the past I did with the Workspace.

> Should the “save" save the code from the playground?

Yes.

> The code from the playground is actually not lost when you close the 
> Playground, and neither is the code you write in the Raw panes. Or is there a 
> different thing you have in mind?

Is not lost, but sometimes I want to reset it (reload) from a previous
saved state. Maybe the latest evaluation isn't what I want to recover.
Also the menu isn't the best option if you have several expressions
that start with the same characters and are indistinguishable from
each other.

I appreciate the "autosave" like feature (although I'd like to be able
to disable it for security paranoid concerns), but I also like to
decide when to save.

But the use case I pointed wasn't about storing the contents outside
of the playground but instead of getting a warning or something when
closing the Playground doing inspection. Sometimes I don't want to
close the playground, just want to reset everything to the original
code pane as if no "Evaluate and Go" was ever ran.

Regards!

Esteban A. Maringolo

Re: [Pharo-dev] why is gt playground not saving the code

[Esteban A. Maringolo]

One use case that sometimes bites me is when I'm working in the "code"
of the Playground (first screen), and then I start going deep with
"Evaluate and Go", basically inspecting my objects, and then I close
the window thinking I'm dealing with an inspector hence losing the
code of the "workspace" in the Playground that started the inspection
"workflow", without receiving any warning about "losing" my changes.

I'd like an explicit "Save" in the Playground, but since I'm not
adding it, I can't complain much. :)

Regards.


Esteban A. Maringolo
Esteban A. Maringolo


2016-08-31 17:10 GMT-03:00 Tudor Girba <tu...@tudorgirba.com>:
> Hi,
>
> The code should actually be saved on disk every time you type. Please take a 
> look at the files from play-cache. Could you confirm?
>
> One bug is that the history is cached and not refreshed, so when you re-open 
> a crashed page the image does not know that there is another file. This has 
> to be changed.
>
> As for having the currently opened playgrounds in the dropdown, we chose it 
> like that because when you open the dropdown you typically want to switch to 
> something else than what exists right now in front of view. Thus showing the 
> same entry again would provide little value. I believe that if we would solve 
> the history bug described above, this issue would resolve itself as well.
>
> In any case, the dealing with the history of the playground is 
> underdeveloped. So, let’s see if we can identify ways to improve the 
> situation.
>
> What do you think?
>
> Cheers,
> Doru
>
>
>> On Aug 31, 2016, at 12:00 PM, Peter Uhnák <i.uh...@gmail.com> wrote:
>>
>> At this point I’ve lost cumulatively hours and hours of work due to 
>> Playground not saving the code; so every time I crash I lose.
>>
>> In the picture below the code was demonstrably executed and yet it’s not in 
>> the history and if I would crash (which happens several times a day in 
>> “stable” pharo 5) I would lose it. Not to mention that way too often I see 
>> duplicate events in the history with identical code…
>>
>> 
>>
>> Peter
>> 
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Speaking louder won't make the point worthier."
>
>

Re: [Pharo-dev] IceBerg and push for projects vs packages

[Esteban A. Maringolo]

2016-08-29 9:12 GMT-03:00 Serge Stinckwich <serge.stinckw...@gmail.com>:
> On Mon, Aug 29, 2016 at 2:08 PM, Esteban Lorenzano <esteba...@gmail.com> 
> wrote:
>>
>>> On 29 Aug 2016, at 14:04, Serge Stinckwich <serge.stinckw...@gmail.com> 
>>> wrote:
>>>
>>> On Mon, Aug 29, 2016 at 10:52 AM, Nicolas Passerini
>>> <npasser...@gmail.com> wrote:
>>>> Well, I am not sure if this has to do with Iceberg itself, because Iceberg
>>>> does nothing with dependencies.
>>>>
>>>> But I am not sure that a ConfigurationOfXXX really has information of only
>>>> one package. Normally you will have only one configuration for each 
>>>> project,
>>>> am I wrong?
>>>> Then the configuration specifies (among other stuff) dependencies between
>>>> the parts (packages) of your project... I think this is right.
>>>> If you depend in another project, then you should not depend in specific
>>>> packages but in another configuration.
>>>
>>> With the Iceberg tool, you can load or unload packages.
>>> How it will works if the dependencies are not loaded before ?
>>
>> AFAIK, this is not iceberg concern… this is a work for metacello (or cargo).
>
> Yes you are right, but when you load a package from Iceberg, the
> dependencies should be loaded at the same time I guess.

No, they shouldn't. Because Iceberg, AFAIU, is for SCM, and Metacello
for dependency management. A proper package manager (Cargo?) should
coordinate artifacts of both.


Esteban A. Maringolo

Re: [Pharo-dev] Epicea import+revert instead of redo+undo changes? (Was: Re: [pharo-project/pharo-core] f57843: 60163)

[Esteban A. Maringolo]

2016-08-19 5:47 GMT-03:00 Esteban Lorenzano <esteba...@gmail.com>:
>
> On 19 Aug 2016, at 10:43, Max Leske <maxle...@gmail.com> wrote:
>
> I think “apply” is better. “import” sounds too specific to me. I don’t want
> to care where the entries come from and “import” implies that there may be
> something else going on (also: if there’s an import where’s the export?).

> +1 :)

+1 here

I was thinking about apply/revert as well.

If you use git-cherry-pick its description says: "Apply the changes
introduced by some existing commits"

I prefer it.

Esteban A. Maringolo

Re: [Pharo-dev] /

[Esteban A. Maringolo]

2016-08-18 17:30 GMT-03:00 Stephan Eggermont <step...@stack.nl>:
> On 18/08/16 14:38, stepharo wrote:
>>
>> Hi
>>
>> In my projects I start to do the following:
>>
>> I create  class method that returns an prototypical instance.
>
>
> Nice. Excellent inititive. I'm not a native speaker, and  does not
> sound like the right name for this to me. That might be me being dutch.
> Native speakers, is this the right name to use?

Semantically it is correct, but for me, also maybe by not being a
native English speaker, sounds weird.

I'd use something like "sample". However I'll be fine with whatever
you choose. But I'd choose something that doesn't sound weird to
native English readers, we already have some cases of that.

Regards,


Esteban A. Maringolo

Re: [Pharo-dev] UDBCSQLite3Statement>>at:putDateTime: and DateAndTime>>readFrom:defaultOffset:

[Esteban A. Maringolo]

As a side note... in all the applications where I use SQLite3, when
storing DateAndTime I use the Unix representation (milliseconds since
epoch) in UTC, although it is unreadable for the end user, it is more
compact, and faster to read/store.

Regards!


Esteban A. Maringolo


2016-06-29 15:43 GMT-03:00 Alistair Grant <akgrant0...@gmail.com>:
> Hi Sven,
>
> On Sun, Jun 26, 2016 at 03:34:15PM +0200, Sven Van Caekenberghe wrote:
>>
>> > On 26 Jun 2016, at 14:59, Alistair Grant <akgrant0...@gmail.com> wrote:
>> >
>> > Hi All,
>> >
>> > UDBCSQLite3Statement>>at:putDateTime: currently writes date and times
>> > using DateAndTime's default print string, i.e.
>> > -MM-DDTHH:MM:SS.mm+hh:ss
>> >
>> > SQLite3 doesn't support timezones, and expects text formatted date/times
>> > to be:
>> >
>> > -MM-DD HH:MM:SS.mmm
>> >
>> > See: https://www.sqlite.org/datatype3.html
>> >
>> > The concensus, as far as I can tell, is that UTC times should always be
>> > stored (which seems to be the only sensible option).
>> >
>> > Changing UDBCSQLite3Statement>>at:putDateTime: to:
>> >
>> > at: aColumn putDateTime: aDateTime
>> > "Put the supplied DateAndTime in column aColumn.
>> >
>> > SQLite3 supports three date/time formats: text, real (Julian day), 
>> > integer (unix seconds).
>> > We use the ISO8601 text format: -MM-DD HH:MM:SS.SSS
>> > See https://www.sqlite.org/datatype3.html;
>> >
>> > | s |
>> >
>> > s := UDBCSQLite3DateTimeString streamContents: [ :stream | |utc |
>> > utc := aDateTime asDateAndTime asUTC.
>> > utc printYMDOn: stream.
>> > stream nextPut: Character space.
>> > utc printHMSOn: stream.
>> > stream nextPut: $..
>> > stream nextPutAll: ((aDateTime nanoSecond / 100) rounded 
>> > printPaddedWith: $0 to: 3) ].
>> > ^ self library with: handle at: aColumn putString: s
>> >
>> >
>> > writes date / times in the correct format.
>> >
>> > Note that SQLite3 doesn't do much in the way of format checking, so the
>> > old implementation didn't raise an error, but can cause problems if the
>> > database is shared with other applications that follow the rules (which
>> > is why I hit this problem).
>> >
>> > To provide some backward compatibility, and follow the rule of being
>> > strict in what you write and forgiving in what you read, we need to
>> > modify UDBCSQLite3Statement>>dateTimeAt: to accept timezones when
>> > supplied, or default to UTC time.
>> >
>> > Unfortunately, the current DateAndTime>>readFrom: method assumes the
>> > local timezone if none is specified.
>> >
>> > I can think of two approaches to solve this:
>> >
>> > 1. Modify UDBCSQLite3Statement>>dateTimeAt: to add 'Z' to the string if
>> > no timezone is specified, i.e. make UTC explicit.
>> >
>> > 2. Extend DateAndTime class to support #readFrom:defaultOffset: so
>> > that UTC can be specified as the default, instead of the local timezone,
>> > and modify UDBCSQLite3Statement>>dateTimeAt: to use UTC as the default.
>> >
>> > I prefer the second approach, but realise that this is a change to the
>> > core Pharo classes, so will implement the first if that is the concensus.
>> > I've included the modified methods for the second approach below.
>>
>> Yes, option 2 is the right way to go. Your code looks OK from a cursory look.
>>
>> Please propose a real slice and make certain you add a couple of good unit 
>> tests, this is really crucial.
>
> Thanks for your feedback.
>
> I'll certainly include automated tests in the slice.
>
> I'm still getting up to speed with fogbugz and the patch system.  Should
> this be submitted as two separate issues (one for the UDBC package and
> one for Kernel-Chronolgy), or as a single issue?
>
> Thanks again,
> Alistair
>
>

Re: [Pharo-dev] [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC

[Esteban A. Maringolo]

2016-06-16 15:29 GMT-03:00 Eliot Miranda <eliot.mira...@gmail.com>:
> Tim,
>
> this morning as I prepared to cone the repository I felt a rush of
> relief spread over me as I realised that I never haves to build and upload
> VMs again.  Thank you, thank you, thank you, everyone who encouraged and
> helped me in making this transition.  I am a happier human as a result.

And this will help giving Smalltalk more exposure in the developers
"social network" that is GitHub.

Esteban A. Maringolo

Re: [Pharo-dev] IMPORTANT: Proposal to create a github team for Voyage and MongoTalk

[Esteban A. Maringolo]

2016-06-09 13:21 GMT-03:00 Martin Dias <tinchod...@gmail.com>:
> On Thu, Jun 9, 2016 at 9:07 AM, Yanni Chiu <yanni.c...@gmail.com> wrote:
>> On Thu, Jun 9, 2016 at 2:58 AM, Esteban Lorenzano <esteba...@gmail.com>
>> wrote:

>>> And finally, more we move, more we have encourage to improve the tools,
>>> complete the missing parts…

>> About a year ago I tried to use git for a project, but gave up because it
>> was not clear to me what tools and processes should be used. Having an
>> active project to follow (like PharoNoSQL) would maybe fill in the missing
>> git knowledge I need.
>>
> Yes, the same happened to me.

Ditto here.

I do use GitHub and Bitbucket for other projects, with branches, pull
requests and all the jazz.
But with Pharo I only used filetree, and I'm never know exactly how
the changes are handled, what's all the metadata thing about, and so
on. But maybe because I commited the same package to both an MC repo
(STHub) and Git.

Regards!


Esteban A. Maringolo

Re: [Pharo-dev] endless loop again

[Esteban A. Maringolo]

2016-06-08 6:29 GMT-03:00 Sven Van Caekenberghe :
>
>> On 08 Jun 2016, at 11:24, Jan Vrany  wrote:
>> Not entirely true :-) There are smalltalks out there that detect such stack 
>> growth and do the same as CL,
>> throw a (resumable) exception. Super-handy. Some of them have this for at 
>> least 10 years now :-)
>
> I was talking about our VM. It is good to know that it already exists in 
> other Smalltalk implementations. You mean Smalltalk/X ?

Dolphin has this feature (see atached file), and AFAIR VisualAge too.
I implemented an infinite recursion, which was handled by Dolphin, but
crashed Pharo.


Regards,

Re: [Pharo-dev] endless loop again

[Esteban A. Maringolo]

Regarding the first part of your email, about UI lockups, it is almost
unavoidable, because in Pharo almost everything happens in the main
thread, as you pointed out. When only UI events should happen there,
and have background processes/async tasks for computation and I/O that
updates the UI by means of some sort of message channel between the
process and the UI.

This isn't a "feature" of Pharo only, other Smalltalks[1] have the
same "design" (or lack thereof) regarding what it is done in the main/UI thread.

I can't imagine a plan for changing that in the current tools, I think
it would require a major overhaul.

OTOH newer tools like Spotter seems to use background threads to do
its stuff, so the shift might have already begun.

Regards,

Esteban A. Maringolo

[1] VisualAge came with an separate OS process that could halt the vm
at a very low level when it was stuck in a tight loop. ST/X has a
process/message queue per os window, which allows you to kill one
window without taking down the whole image/vm.

2016-06-03 2:56 GMT-03:00 stepharo <steph...@free.fr>:
> the mooc is a mine for Pharo bugs...
>
>
> In the video at 6:12, we have a new method sending the new message. I've
> made similar mistakes and Pharo does lock up, but then the operating system
> (Windows 10) kills the Pharo VM. (Or perhaps there's a bug in Pharo itself
> which just crashes the whole VM. I can't tell the difference.)
> Is that because it's a memory leak? Does the VM have a fixed amount of
> memory available, or can it request more from the OS?
> Is there a way to recover from this error without killing the whole VM?
> Most GUI systems I've used have at least two threads so that pushing a
> button doesn't lock up the whole UI if the task takes a while. Does Pharo
> always lock up for long-running tasks, or does it have some kind of
> threading ability too? If a background thread gets in an infinite loop, how
> do you kill it without killing the whole VM?
>
>
> here was my answer
>
> The real answer is a bit more complex so I may write some approximations: -
> what you did a really tight loops that fills up the memory really fast. -
> depending on the OS the VM can or not (in its current state) allocate more.
> In some versions it has to preallocate.
> "Most GUI systems I've used have at least two threads so that pushing a
> button doesn't lock up the whole UI if the task takes a while. Does Pharo
> always lock up for long-running tasks, or does it have some kind of
> threading ability too? If a background thread gets in an infinite loop, how
> do you kill it without killing the whole VM?"
> Pharo has a full model for concurrent programming. Check the class Process,
> Semaphore. We have some stress tests that create thousands of threads
> without problems. You have also package such TaskIt to schedule tasks
> Now the actual problem that you see and that I would love to see fix in the
> future is that the code you execute is run in the UI thread (argh) It is
> still like that for historical reason. We should do one pass on that but
> this is not that simple because it will raise a couple of bugs.
>
>
> Now I think that it would be great if people from the pharo core would
> browse in diagonal the problems that students
>
> encounter because there are our real customers and they show many problems
> of the system. Especially the ones we do not see anymore.
>
>

[Pharo-dev] Jenkins CI error

[Esteban A. Maringolo]

Who is in charge of the Jenkins installation for http://ci.inria.fr/dbxtalk.

I'm trying to modify certain projects and I'm getting the following error:

Error
JSONObject["scm"] is not a JSONObject.

I tried some hacks to make it work, but no luck.

Did this happen to somebody else? How to fix it?

Regards!

Esteban A. Maringolo

Re: [Pharo-dev] About PharoInProgress book

[Esteban A. Maringolo]

Damien:

One thing I noticed with the new PDF rendering is that the code
listings does not appear in the order they are in the Pillar file, so
I can't be sure that a code block will follow a certain paragraph,
hence I can't say "in the following example code", because the example
might have appeared three paragraphs ago.

Can that be avoided? And if not... how can I "link" or add a reference
to such code block?

Regards!

Esteban A. Maringolo


2016-05-04 4:14 GMT-03:00 stepharo <steph...@free.fr>:
> Yes this is on my todo.
>
>
> Le 3/5/16 à 14:01, Damien Pollet a écrit :
>
> The interns updated the stable release of Pillar; there is a mention of the
> listings package in the log, which suggests that pillar outputs TeX code for
> the new sbabook class instead of the old one. That should be fixable by
> finding the correct version of Pillar to use, but the correct long-term fix
> is to migrate to sbabook.
>
> On 27 April 2016 at 22:28, Esteban A. Maringolo <emaring...@gmail.com>
> wrote:
>>
>> I sent an email this morning about this issue, apparently it has to do
>> with a missing font.
>>
>> Esteban A. Maringolo
>>
>>
>> 2016-04-27 16:50 GMT-03:00 stepharo <steph...@free.fr>:
>> > Hi
>> >
>> > I tried to fix the build on jenkins but I failed. I do not know how to
>> > fix
>> > it.
>> >
>> > I do not know how to fix. Probably the changes in Pillar broke it.
>> >
>> > Now since Damien will quit our team, I wonder what will be the future of
>> > pillar, may be markdown and for me LaTeX
>> >
>> > Stef
>> >
>> >
>> >
>> > ./AWS.tex:40: LaTeX Error: Environment listing undefined.
>> >
>> > See the LaTeX manual or LaTeX Companion for explanation.
>> > Type  H   for immediate help.
>> > ...
>> >
>> > l.40 \begin{listing}
>> >  [language=smalltalk]
>> > Your command was ignored.
>> > Type  Ito replace it with another command,
>> > orto continue without it.
>> >
>> >
>> > ./AWS.tex:53: LaTeX Error: \begin{document} ended by \end{listing}.
>> >
>> > See the LaTeX manual or LaTeX Companion for explanation.
>> > Type  H   for immediate help.
>> > ...
>> >
>> > l.53 \end{listing}
>> >
>> > Your command was ignored.
>> > Type  Ito replace it with another command,
>> > orto continue without it.
>> >
>> > No file AWS.bbl.
>> >
>> >
>>
>
>
>
> --
> Damien Pollet
> type less, do more [ | ] http://people.untyped.org/damien.pollet
>
>

Re: [Pharo-dev] About PharoInProgress book

[Esteban A. Maringolo]

Thanks Damien! It is working again.

https://ci.inria.fr/pharo-contribution/job/PharoBookWorkInProgress/101/changes
Esteban A. Maringolo


2016-05-03 15:17 GMT-03:00 Damien Pollet <damien.pol...@gmail.com>:
> I did the migration, now waiting for the CI to run a build. On my machine it
> looked fine.
>
> SBAbook is a LaTeX class I made for the Pharo books, that's what defines the
> new look of e.g. Enterprise Pharo
>
> On 3 May 2016 at 19:43, Esteban A. Maringolo <emaring...@gmail.com> wrote:
>>
>> Hi Damien,
>>
>> Sorry, I don't know what SBABook is :)
>> Who maintains the CI?  Is it easily fixable?
>>
>> I could get TeX running locally following your advice, so I can build
>> the book's PDFs on my own machine. I guess doing the same on the build
>> slave should be as straightforward as that.
>>
>> Regards!
>> Esteban A. Maringolo
>>
>>
>> 2016-05-03 9:01 GMT-03:00 Damien Pollet <damien.pol...@gmail.com>:
>> > The interns updated the stable release of Pillar; there is a mention of
>> > the
>> > listings package in the log, which suggests that pillar outputs TeX code
>> > for
>> > the new sbabook class instead of the old one. That should be fixable by
>> > finding the correct version of Pillar to use, but the correct long-term
>> > fix
>> > is to migrate to sbabook.
>> >
>> > On 27 April 2016 at 22:28, Esteban A. Maringolo <emaring...@gmail.com>
>> > wrote:
>> >>
>> >> I sent an email this morning about this issue, apparently it has to do
>> >> with a missing font.
>> >>
>> >> Esteban A. Maringolo
>> >>
>> >>
>> >> 2016-04-27 16:50 GMT-03:00 stepharo <steph...@free.fr>:
>> >> > Hi
>> >> >
>> >> > I tried to fix the build on jenkins but I failed. I do not know how
>> >> > to
>> >> > fix
>> >> > it.
>> >> >
>> >> > I do not know how to fix. Probably the changes in Pillar broke it.
>> >> >
>> >> > Now since Damien will quit our team, I wonder what will be the future
>> >> > of
>> >> > pillar, may be markdown and for me LaTeX
>> >> >
>> >> > Stef
>> >> >
>> >> >
>> >> >
>> >> > ./AWS.tex:40: LaTeX Error: Environment listing undefined.
>> >> >
>> >> > See the LaTeX manual or LaTeX Companion for explanation.
>> >> > Type  H   for immediate help.
>> >> > ...
>> >> >
>> >> > l.40 \begin{listing}
>> >> >  [language=smalltalk]
>> >> > Your command was ignored.
>> >> > Type  Ito replace it with another command,
>> >> > orto continue without it.
>> >> >
>> >> >
>> >> > ./AWS.tex:53: LaTeX Error: \begin{document} ended by \end{listing}.
>> >> >
>> >> > See the LaTeX manual or LaTeX Companion for explanation.
>> >> > Type  H   for immediate help.
>> >> > ...
>> >> >
>> >> > l.53 \end{listing}
>> >> >
>> >> > Your command was ignored.
>> >> > Type  Ito replace it with another command,
>> >> > orto continue without it.
>> >> >
>> >> > No file AWS.bbl.
>> >> >
>> >> >
>> >>
>> >
>> >
>> >
>> > --
>> > Damien Pollet
>> > type less, do more [ | ] http://people.untyped.org/damien.pollet
>>
>
>
>
> --
> Damien Pollet
> type less, do more [ | ] http://people.untyped.org/damien.pollet

Re: [Pharo-dev] About PharoInProgress book

[Esteban A. Maringolo]

Hi Damien,

Sorry, I don't know what SBABook is :)
Who maintains the CI?  Is it easily fixable?

I could get TeX running locally following your advice, so I can build
the book's PDFs on my own machine. I guess doing the same on the build
slave should be as straightforward as that.

Regards!
Esteban A. Maringolo


2016-05-03 9:01 GMT-03:00 Damien Pollet <damien.pol...@gmail.com>:
> The interns updated the stable release of Pillar; there is a mention of the
> listings package in the log, which suggests that pillar outputs TeX code for
> the new sbabook class instead of the old one. That should be fixable by
> finding the correct version of Pillar to use, but the correct long-term fix
> is to migrate to sbabook.
>
> On 27 April 2016 at 22:28, Esteban A. Maringolo <emaring...@gmail.com>
> wrote:
>>
>> I sent an email this morning about this issue, apparently it has to do
>> with a missing font.
>>
>> Esteban A. Maringolo
>>
>>
>> 2016-04-27 16:50 GMT-03:00 stepharo <steph...@free.fr>:
>> > Hi
>> >
>> > I tried to fix the build on jenkins but I failed. I do not know how to
>> > fix
>> > it.
>> >
>> > I do not know how to fix. Probably the changes in Pillar broke it.
>> >
>> > Now since Damien will quit our team, I wonder what will be the future of
>> > pillar, may be markdown and for me LaTeX
>> >
>> > Stef
>> >
>> >
>> >
>> > ./AWS.tex:40: LaTeX Error: Environment listing undefined.
>> >
>> > See the LaTeX manual or LaTeX Companion for explanation.
>> > Type  H   for immediate help.
>> > ...
>> >
>> > l.40 \begin{listing}
>> >  [language=smalltalk]
>> > Your command was ignored.
>> > Type  Ito replace it with another command,
>> > orto continue without it.
>> >
>> >
>> > ./AWS.tex:53: LaTeX Error: \begin{document} ended by \end{listing}.
>> >
>> > See the LaTeX manual or LaTeX Companion for explanation.
>> > Type  H   for immediate help.
>> > ...
>> >
>> > l.53 \end{listing}
>> >
>> > Your command was ignored.
>> > Type  Ito replace it with another command,
>> > orto continue without it.
>> >
>> > No file AWS.bbl.
>> >
>> >
>>
>
>
>
> --
> Damien Pollet
> type less, do more [ | ] http://people.untyped.org/damien.pollet