November 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [IMPORTANT] Is there a bug in Tonel with category:

by Stephane Ducasse

Esteban told me that this is because he uses STON for the class definition. Now a simple question may be we could use a string instead of a symbol because this is strange to have a class definitino that does not respect Pharo syntax. Stef On Mon, Nov 6, 2017 at 8:15 PM, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > > > On 11/06/2017 08:23 AM, Sven Van Caekenberghe wrote: >> >> >>> On 6 Nov 2017, at 17:13, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> >>> wrote: >>> >>> >>> >>> On 11/6/17 7:07 AM, Sven Van Caekenberghe wrote: >>>>> >>>>> On 6 Nov 2017, at 15:43, Dale Henrichs >>>>> <dale.henrichs(a)gemtalksystems.com> wrote: >>>>> >>>>> of course with Pharo's implementation of Symbol it is not practical to >>>>> use asString nor type checks - things that are not necessary in other >>>>> Smalltalk implementations >>>> >>>> How so ? >>>> >>>> What is the problem with Symbol>>#asString ? >>> >>> I am not going to go to every field in the api that is supposed to be a >>> String and add asString. There are too many places to worry about ... I >>> would prefer that Pharo be ANSI compliant:) >>> >>> It's not just Metacello. >>> >>> It's an annoying issue that has to be dealt with every time a Pharo >>> application is ported to another dialect of Smalltalk and an annoying >>> barrier for folks running on other dialects to move their application to >>> Pharo - in this case the bugs that are introduced by Pharo's behavior with >>> respect to Symbols can be very hard to diagnose -- >>> >>> Making things harder to share code between dialects is a bad thing for >>> Smalltalk overall -- just another reason for non-Smalltalk programmers to >>> question the whether they should use Smalltalk or not... >>> >>> And I don't need to hear about how Pharo is not Smalltalk:) >>> >>> Dale >> >> So there is nothing 'wrong', you just want Pharo to remain the same as >> every other non-changing Smalltalk out there. > > Did I say that? > > I support the direction that Pharo is going, but I reserve the right to > disagree with some of the details. > > This is just one detail ... nothing more nothing less ... For those of us > that work in multiple dialects, it IS annoying and I take an opportunity > every year or so to remind you guys of the things that I find annoying, just > to keep you guys honest:) > >> >> From one perspective you are right, it makes some cross platform porting >> in either direction harder. Seaside has many rules to help portability. Not >> mixing Strings and Symbol is probably one of them. > > ... and as I mentioned, this problem can be one of the more annoying issues > to track down, when a developer is not careful ... Honestly there are two > sides to the issue ... when developers use Symbols in tests to drive an API > that is supposed to use Strings (this happens the most often) things break > pretty quickly and the tests can be fixed pretty easily ... but when the > code itself is written with mixed Symbols and Strings, the tests might > actually pass after the port, and the bugs will only show up in subtle cases > ... I've hit a handful of these over the years and they are hard to track > down... >> >> >> But you know very well that Pharo was started so that we would be able to >> make changes, in any area or aspect of the system, without the burden of >> backwards or cross platform compatibility, even if some of these changes are >> taste based. > > Agree with your statement -- most of the changes that Pharo has made have > not been difficult to accommodate, but Symbol/String is at a fundamental > level and I'm not sure that it would be "illegal" to make this accommodation > --- I AM pretty certain that it would cause some short term pain, but > probably no more pain (and likely less pain) than is caused by trying to > move an application to a new version of Pharo:) >> >> And I happen to like the ability to mix and match Strings and Symbols (we >> discussed about this before). >> > I won't argue with taste, it's is simply the portability for this particular > problem that I am highlighting ... > > Dale >

Nov. 6, 2017

Re: [Pharo-dev] [IMPORTANT] Is there a bug in Tonel with category:

by Dale Henrichs

On 11/06/2017 08:23 AM, Sven Van Caekenberghe wrote: > >> On 6 Nov 2017, at 17:13, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: >> >> >> >> On 11/6/17 7:07 AM, Sven Van Caekenberghe wrote: >>>> On 6 Nov 2017, at 15:43, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: >>>> >>>> of course with Pharo's implementation of Symbol it is not practical to use asString nor type checks - things that are not necessary in other Smalltalk implementations >>> How so ? >>> >>> What is the problem with Symbol>>#asString ? >> I am not going to go to every field in the api that is supposed to be a String and add asString. There are too many places to worry about ... I would prefer that Pharo be ANSI compliant:) >> >> It's not just Metacello. >> >> It's an annoying issue that has to be dealt with every time a Pharo application is ported to another dialect of Smalltalk and an annoying barrier for folks running on other dialects to move their application to Pharo - in this case the bugs that are introduced by Pharo's behavior with respect to Symbols can be very hard to diagnose -- >> >> Making things harder to share code between dialects is a bad thing for Smalltalk overall -- just another reason for non-Smalltalk programmers to question the whether they should use Smalltalk or not... >> >> And I don't need to hear about how Pharo is not Smalltalk:) >> >> Dale > So there is nothing 'wrong', you just want Pharo to remain the same as every other non-changing Smalltalk out there. Did I say that? I support the direction that Pharo is going, but I reserve the right to disagree with some of the details. This is just one detail ... nothing more nothing less ... For those of us that work in multiple dialects, it IS annoying and I take an opportunity every year or so to remind you guys of the things that I find annoying, just to keep you guys honest:) > > From one perspective you are right, it makes some cross platform porting in either direction harder. Seaside has many rules to help portability. Not mixing Strings and Symbol is probably one of them. ... and as I mentioned, this problem can be one of the more annoying issues to track down, when a developer is not careful ... Honestly there are two sides to the issue ... when developers use Symbols in tests to drive an API that is supposed to use Strings (this happens the most often) things break pretty quickly and the tests can be fixed pretty easily ... but when the code itself is written with mixed Symbols and Strings, the tests might actually pass after the port, and the bugs will only show up in subtle cases ... I've hit a handful of these over the years and they are hard to track down... > > But you know very well that Pharo was started so that we would be able to make changes, in any area or aspect of the system, without the burden of backwards or cross platform compatibility, even if some of these changes are taste based. Agree with your statement -- most of the changes that Pharo has made have not been difficult to accommodate, but Symbol/String is at a fundamental level and I'm not sure that it would be "illegal" to make this accommodation --- I AM pretty certain that it would cause some short term pain, but probably no more pain (and likely less pain) than is caused byÂ trying to move an application to a new version of Pharo:) > And I happen to like the ability to mix and match Strings and Symbols (we discussed about this before). > I won't argue with taste, it's is simply the portability for this particular problem that I am highlighting ... Dale

Nov. 6, 2017

Re: [Pharo-dev] [IMPORTANT] Is there a bug in Tonel with category:

by Nicolas Cellier

2017-11-06 18:20 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > > On 6 Nov 2017, at 17:25, Nicolas Cellier <nicolas.cellier.aka.nice@gmai > l.com> wrote: > > > > > > > > 2017-11-06 17:23 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > > > > > On 6 Nov 2017, at 17:13, Dale Henrichs <dale.henrichs@gemtalksystems. > com> wrote: > > > > > > > > > > > > On 11/6/17 7:07 AM, Sven Van Caekenberghe wrote: > > >> > > >>> On 6 Nov 2017, at 15:43, Dale Henrichs < > dale.henrichs(a)gemtalksystems.com> wrote: > > >>> > > >>> of course with Pharo's implementation of Symbol it is not practical > to use asString nor type checks - things that are not necessary in other > Smalltalk implementations > > >> How so ? > > >> > > >> What is the problem with Symbol>>#asString ? > > > I am not going to go to every field in the api that is supposed to be > a String and add asString. There are too many places to worry about ... I > would prefer that Pharo be ANSI compliant:) > > > > > > It's not just Metacello. > > > > > > It's an annoying issue that has to be dealt with every time a Pharo > application is ported to another dialect of Smalltalk and an annoying > barrier for folks running on other dialects to move their application to > Pharo - in this case the bugs that are introduced by Pharo's behavior with > respect to Symbols can be very hard to diagnose -- > > > > > > Making things harder to share code between dialects is a bad thing for > Smalltalk overall -- just another reason for non-Smalltalk programmers to > question the whether they should use Smalltalk or not... > > > > > > And I don't need to hear about how Pharo is not Smalltalk:) > > > > > > Dale > > > > So there is nothing 'wrong', you just want Pharo to remain the same as > every other non-changing Smalltalk out there. > > > > From one perspective you are right, it makes some cross platform porting > in either direction harder. Seaside has many rules to help portability. Not > mixing Strings and Symbol is probably one of them. > > > > But you know very well that Pharo was started so that we would be able > to make changes, in any area or aspect of the system, without the burden of > backwards or cross platform compatibility, even if some of these changes > are taste based. > > > > And I happen to like the ability to mix and match Strings and Symbols > (we discussed about this before). > > > > Sven > > > > > > > > Note that it's not entirely Pharo's fault. > > #foo = 'foo' in Squeak too. > > It is neither Squeak's 'fault'. > > It is a choice, just like you prefer #<=> over our #threeWayCompareTo: > > There are valid reasons for such choices, if a community choses or prefers > one way or the other it is not a fault, it is a feature. > Agree, the POV is: Symbol are just special String optimized for space. But then one must assume the cost of hischoices and provide appropriate transforms for communicating with external world. If a file exchange format or cross platform package specification requires a String, it's his responsability to provide a String... I shouldn't change the ston format just because it would ease some implementation in Squeak, should I?

Nov. 6, 2017

Re: [Pharo-dev] about SortFunctions

by Martin Dias

On Mon, Nov 6, 2017 at 10:20 AM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > 2017-11-06 10:51 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > >> >> >> > On 6 Nov 2017, at 10:37, Nicolas Cellier <nicolas.cellier.aka.nice@gmai >> l.com> wrote: >> > >> > Because it's a cross dialect library and because contributing in Squeak >> is so much easier for me. >> > >> > I like the social power provided by github and i know how to use git, >> at least as an expert beginner. >> > But it took me two hours to pick a pharo image, fork and clone the >> pharo repository, pick a pharo VM (I ended up building my own), >> > retrieve my ssh pass phrase to avoid using github thru https, >> > search documentation of where should I put the image wrt to my cloned >> git repository, >> > search how to use iceberg, >> > and finally realized that the author/date would not even be preserved >> if we want to port this cross dialect library. >> >> You are absolutely right, but it is improving and will get better. >> >> > Nope, i don't buy the argument... > The information has simply been erased and won't reappear by operation of > wishfull thinking > Even if we later add the blame API, the information of original authors is > definitely lost. > > That was already the case at each Pharo release, the mc ancestry was reset > and it was very difficult to trace back. > 7.0 is in continuity, just with a more radical eradication. > > For Pharo, such compatibility is a drag, for me it's usefull, it's just > that we have different trade offs > It's not for complaining, but trade offs are to be made explicit and > assumed. > > > > The dark theme upsets me, especially the green on blue, I could have >> searched how to change it, but there I stopped. >> >> Then switch to the light/white theme, just one setting. >> >> > While doing all these things, I did not spent a minute focusing on the >> SortFunction subject. >> > I can see that as an investment, maybe I should have done it before, >> but it was too much for a Sunday evening. >> >> I think what Denis means is, it would have been helpful to apply the >> change in Pharo. How you communicate that is less relevant, just saving the >> MC version and mailing it would already have been very helpful. >> >> IMHO. >> > > Right, I can understand that cross dialect is becoming inconvenient... > That's why I gave the .diff URL just for giving a chance to glimpse at > refactoring POC. > > Pharo still has Monticello, so it could have worked (not sure how well > without common ancestor) > The extra difficulty here is that package delimitation does not match, > SortFunction has been integrated into Collection in Squeak. > Hi, punctually about this: > Is extracting sources From .mcz and filtering in change list still > possible? (Epicea?) > Yes, in latest Pharo 6 and 7 you can file browse or drag&drop the source.st inside the .mcz to either file-in or see the code. (But no, it's not Epicea). Martin > I will try and import in Pharo. But it was not humanely possible yesterday > night. > > >> > 2017-11-06 10:13 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >> > It is difficult to compare to current Pharo version. >> > Why you not produce Pharo pull request? >> > >> > 2017-11-06 0:06 GMT+01:00 Nicolas Cellier < >> nicolas.cellier.aka.nice(a)gmail.com>: >> > I've put some of the proposed composition features into >> > >> > http://source.squeak.org/inbox/Collections-nice.766.mcz >> > http://source.squeak.org/inbox/CollectionsTests-nice.283.mcz >> > >> > http://source.squeak.org/inbox/Collections-nice.766.diff >> > http://source.squeak.org/inbox/CollectionsTests-nice.283.diff >> > >> > SInce it's Squeak based, it uses <=>, but never mind, that's the same >> functions. >> > >> > >> > Stephane: the original comments were from Travis Griggs. >> > It's more a tutorial for using the SortFunction than a detailed >> explanation of implementation. >> > >> > The original idea is that oSortFunction are composable. >> > For example, it's possible to chain sorting on a first criterion, then >> resort on a second criterion if objects have same rank with first. >> > >> > For this, we need a to distinguish when objects have same rank (=) and >> cannot use a binary result (Boolean) like legacy sortBlock, >> > So we rather need a ternary comparison (<=>). >> > >> > This thread is about extending composition, and generalizing >> implementation by composition (like Xtreams) >> > - for sorting nil first (or last) >> > - for reversing the order >> > - for sorting properties with any collation order, and not just default >> <=> >> > >> > 2017-11-05 17:52 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >> > Hi guys >> > >> > Do you have some nice comments somewhere? because I do not understand >> > anything about this thread. >> > I check the code and the comments are well... unclear and confusing. >> > >> > Stef >> > >> > On Sun, Nov 5, 2017 at 4:15 PM, Nicolas Cellier >> > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> > > >> > > >> > > 2017-11-05 16:06 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >> > >> >> > >> >> > >> 2017-11-05 11:33 GMT+01:00 Nicolas Cellier >> > >> <nicolas.cellier.aka.nice(a)gmail.com>: >> > >>> >> > >>> >> > >>> Ah, I messed up, UndefinedSorter must not be chained, it must be a >> > >>> wrapper! >> > >>> Otherwise comparing to nil will resort to sorting by properties and >> > >>> fail... >> > >>> >> > >>> SortFunction>>undefinedFirst >> > >>> ^UndefinedSorter descending wrap: self >> > >>> >> > >>> UndefinedSorter>> collate: value1 with: value2 >> > >>> "sort all nil according to the direction (first if -1, last >> if >> > >>> +1), then" >> > >>> value1 ifNil: [value2 ifNil: [^0] ifNotNil: [^direction]]. >> > >>> value2 ifNil: [^direction negated]. >> > >>> ^sorterForNonNil collate: value1 with: value2 >> > >>> >> > >>> It's important to have the UndefinedSorter : >> > >>> - decoupled from property sort, because it can be generally >> usefull >> > >>> - collating 2 nil as 0, so that another property can be chained >> > >> >> > >> >> > >> I like your idea. >> > >> It also forced me to think that direction itself should be >> implemented as >> > >> wrapper. I would name it InvertedSortFunction: >> > >> >> > >> InvertedSortFunction>>collate: value1 with: value2 >> > >> ^(actualSortFunction collate: value1 with: value2) * -1 >> > >> >> > >> >> > >> If we will do it then direction will be not part of SortFunction. >> And all >> > >> current functions will be in fact ascending. >> > >> And to explicitly reflect this fact I would introduce >> > >> AscendingSortFunction as their superclass. >> > >> InvertedSortFunction and ChainedSortFunction will stay subclasses of >> > >> SortFunction. >> > >> >> > >> So what you think? >> > > >> > > >> > > Yes, I was thinking the same. >> > > On another hand, direction makes thing symmetric and has its elegance >> too. >> > > What I don't like with it is that it forces the library to have two >> > > different messages for the same thing: >> > > - collate:with: in base class accounting for direction >> > > - threeWayCompare:with: in every subclass >> > > >> > > The fact to hardcode the direction in base class could be seen as an >> > > optimization too. >> > > I'm not sure what Sista optimization could bring in this case, >> because the >> > > selectors may get megamorphic... >> > > >> > > >> > >> >> > >>> >> > >>> >> > >>> In >> > >>> >> > >>> people sortBy: #name ascending undefinedFirst , #age descending >> > >>> >> > >>> we could then have people with name nil still sorted by age, what >> is not >> > >>> possible with current implementation >> > >>> >> > >> >> > > >> > >> > >> > >> > >> >> >> >

Nov. 6, 2017

Re: [Pharo-dev] [IMPORTANT] Is there a bug in Tonel with category:

by Sven Van Caekenberghe

> On 6 Nov 2017, at 17:25, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > > 2017-11-06 17:23 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > > On 6 Nov 2017, at 17:13, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > > > > > > > > On 11/6/17 7:07 AM, Sven Van Caekenberghe wrote: > >> > >>> On 6 Nov 2017, at 15:43, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > >>> > >>> of course with Pharo's implementation of Symbol it is not practical to use asString nor type checks - things that are not necessary in other Smalltalk implementations > >> How so ? > >> > >> What is the problem with Symbol>>#asString ? > > I am not going to go to every field in the api that is supposed to be a String and add asString. There are too many places to worry about ... I would prefer that Pharo be ANSI compliant:) > > > > It's not just Metacello. > > > > It's an annoying issue that has to be dealt with every time a Pharo application is ported to another dialect of Smalltalk and an annoying barrier for folks running on other dialects to move their application to Pharo - in this case the bugs that are introduced by Pharo's behavior with respect to Symbols can be very hard to diagnose -- > > > > Making things harder to share code between dialects is a bad thing for Smalltalk overall -- just another reason for non-Smalltalk programmers to question the whether they should use Smalltalk or not... > > > > And I don't need to hear about how Pharo is not Smalltalk:) > > > > Dale > > So there is nothing 'wrong', you just want Pharo to remain the same as every other non-changing Smalltalk out there. > > From one perspective you are right, it makes some cross platform porting in either direction harder. Seaside has many rules to help portability. Not mixing Strings and Symbol is probably one of them. > > But you know very well that Pharo was started so that we would be able to make changes, in any area or aspect of the system, without the burden of backwards or cross platform compatibility, even if some of these changes are taste based. > > And I happen to like the ability to mix and match Strings and Symbols (we discussed about this before). > > Sven > > > > Note that it's not entirely Pharo's fault. > #foo = 'foo' in Squeak too. It is neither Squeak's 'fault'. It is a choice, just like you prefer #<=> over our #threeWayCompareTo: There are valid reasons for such choices, if a community choses or prefers one way or the other it is not a fault, it is a feature.

Nov. 6, 2017

Re: [Pharo-dev] SqueakSSL on Pharo 64bit/Win

by Raffaello Giulietti

Hi Nicolas, I understand. And I can confirm that the Squeak 64 bit/win VM SqueakSSL.dll works when copied in the Pharo 64 bit/win folder. Thanks for the patience Raffaello On 2017-11-06 17:21, Nicolas Cellier wrote: > No matter which step fails, the build is considered failed if return > code differs from 0... > > 2017-11-06 15:23 GMT+01:00 Raffaello Giulietti > <raffaello.giulietti(a)lifeware.ch <mailto:raffaello.giulietti@lifeware.ch>>: > > Hi Nicolas, > > seems that only the upload to the Pharo repo fails, not the building > by itself. > > But the cog_win64x64_pharo.stack.spur_201711061254.zip is not even > on the bintray repo. I would expect it at least there. Is that > right? Just wondering... > > Of course, I'll try to grab the SqueakSSL.dll from the squeak 64 > bit/win vm. > > > > > On 2017-11-06 15:05, Nicolas Cellier wrote: > > Unfortunately, the VM is corectly built, but the script fails at > deploy stage... > https://ci.appveyor.com/project/OpenSmalltalk/vm/branch/Cog/job/gx20b215gls… > <https://ci.appveyor.com/project/OpenSmalltalk/vm/branch/Cog/job/gx20b215gls…> > > Uploading ./pharo-win-x86_64-201711061254-f819c8f.zip to > pharo.files.org//appli/files.pharo.org/vm/pharo-spur64/win > <http://pharo.files.org//appli/files.pharo.org/vm/pharo-spur64/win> > <http://pharo.files.org//appli/files.pharo.org/vm/pharo-spur64/win > <http://pharo.files.org//appli/files.pharo.org/vm/pharo-spur64/win>> > Warning: Permanently added the RSA host key for IP address > '193.51.193.142' to the list of known hosts. > Uploading ./pharo-win-x86_64-201711061254-f819c8f.zip to > pharo.files.org//appli/files.pharo.org/vm/pharo-spur64/win/latest.zip > <http://pharo.files.org//appli/files.pharo.org/vm/pharo-spur64/win/latest.zip> > <http://pharo.files.org//appli/files.pharo.org/vm/pharo-spur64/win/latest.zip > <http://pharo.files.org//appli/files.pharo.org/vm/pharo-spur64/win/latest.zip>> > scp: /appli/files.pharo.org/vm/pharo-spur64/win/latest.zip > <http://files.pharo.org/vm/pharo-spur64/win/latest.zip> > <http://files.pharo.org/vm/pharo-spur64/win/latest.zip > <http://files.pharo.org/vm/pharo-spur64/win/latest.zip>>: > Permission denied > Command exited with code 1 > > At this stage, there's not much i can do. > You'll have to ask to Pharo team to correct this problem. > > In the interim, I suggest you download the Squeak VM for Win64 > and pick SqueakSSL.dll there... > > 2017-11-06 11:34 GMT+01:00 Raffaello Giulietti > <raffaello.giulietti(a)lifeware.ch > <mailto:raffaello.giulietti@lifeware.ch> > <mailto:raffaello.giulietti@lifeware.ch > <mailto:raffaello.giulietti@lifeware.ch>>>: > > Â Â Thanks Nicolas! > > > > Â Â On 2017-11-06 11:30, Nicolas Cellier wrote: > > Â Â Â Â Oh yes, you're right, > Â Â Â Â the SqueakSLL could have been built but was not built > in pharo... > Â Â Â Â I just changed > https://github.com/OpenSmalltalk/opensmalltalk-vm/edit/Cog/build.win64x64/p… > <https://github.com/OpenSmalltalk/opensmalltalk-vm/edit/Cog/build.win64x64/p…> > > <https://github.com/OpenSmalltalk/opensmalltalk-vm/edit/Cog/build.win64x64/p… > <https://github.com/OpenSmalltalk/opensmalltalk-vm/edit/Cog/build.win64x64/p…>> > Â Â Â Â this should trigger another automated build and if all > goes well > Â Â Â Â you will have a new bintray artefact to test. > > Â Â Â Â 2017-11-06 10:21 GMT+01:00 Raffaello Giulietti > Â Â Â Â <raffaello.giulietti(a)lifeware.ch > <mailto:raffaello.giulietti@lifeware.ch> > Â Â Â Â <mailto:raffaello.giulietti@lifeware.ch > <mailto:raffaello.giulietti@lifeware.ch>> > Â Â Â Â <mailto:raffaello.giulietti@lifeware.ch > <mailto:raffaello.giulietti@lifeware.ch> > > Â Â Â Â <mailto:raffaello.giulietti@lifeware.ch > <mailto:raffaello.giulietti@lifeware.ch>>>>: > > > Â Â Â Â Â Â Â Hi Nicolas, > > Â Â Â Â Â Â Â I tried both the vm found at the location you > mention (dated > Â Â Â Â Â Â Â 2017-10-22): > > https://bintray.com/opensmalltalk/vm/download_file?file_path=cog_win64x64_p… > <https://bintray.com/opensmalltalk/vm/download_file?file_path=cog_win64x64_p…> > > <https://bintray.com/opensmalltalk/vm/download_file?file_path=cog_win64x64_p… > <https://bintray.com/opensmalltalk/vm/download_file?file_path=cog_win64x64_p…>> > > <https://bintray.com/opensmalltalk/vm/download_file?file_path=cog_win64x64_p… > <https://bintray.com/opensmalltalk/vm/download_file?file_path=cog_win64x64_p…> > > <https://bintray.com/opensmalltalk/vm/download_file?file_path=cog_win64x64_p… > <https://bintray.com/opensmalltalk/vm/download_file?file_path=cog_win64x64_p…>>> > > Â Â Â Â Â Â Â and the "official" latest vm on the Pharo site (dated > Â Â Â Â 2017-11-01) > > http://files.pharo.org/vm/pharo-spur64/win/pharo-win-x86_64-201711010928-e1… > <http://files.pharo.org/vm/pharo-spur64/win/pharo-win-x86_64-201711010928-e1…> > > <http://files.pharo.org/vm/pharo-spur64/win/pharo-win-x86_64-201711010928-e1… > <http://files.pharo.org/vm/pharo-spur64/win/pharo-win-x86_64-201711010928-e1…>> > > <http://files.pharo.org/vm/pharo-spur64/win/pharo-win-x86_64-201711010928-e1… > <http://files.pharo.org/vm/pharo-spur64/win/pharo-win-x86_64-201711010928-e1…> > > <http://files.pharo.org/vm/pharo-spur64/win/pharo-win-x86_64-201711010928-e1… > <http://files.pharo.org/vm/pharo-spur64/win/pharo-win-x86_64-201711010928-e1…>>> > > > > Â Â Â Â Â Â Â Neither of them contains the SqueakSSL.dll and, in > fact, in > Â Â Â Â both > Â Â Â Â Â Â Â cases I get an exception when using Gofer to > download Roassal2, > Â Â Â Â Â Â Â using the latest 60519 image: > > Â Â Â Â Â Â Â Gofer it > Â Â Â Â Â Â Â Â Â Â smalltalkhubUser: 'ObjectProfile' project: > 'Roassal2'; > Â Â Â Â Â Â Â Â Â Â configurationOf: 'Roassal2'; > Â Â Â Â Â Â Â Â Â Â loadDevelopment > > Â Â Â Â Â Â Â This works on Pharo 32 bit/Win, where SquekSSL is > present. > > > > > > > > > Â Â Â Â Â Â Â On 2017-11-04 23:31, Nicolas Cellier wrote: > > Â Â Â Â Â Â Â Â Â Note that win64 SSL works at least since > https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/baa70862014d3bb510… > <https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/baa70862014d3bb510…> > > <https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/baa70862014d3bb510… > <https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/baa70862014d3bb510…>> > > <https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/baa70862014d3bb510… > <https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/baa70862014d3bb510…> > > <https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/baa70862014d3bb510… > <https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/baa70862014d3bb510…>>> > Â Â Â Â Â Â Â Â Â and > https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/caa8241de11b99ecae… > <https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/caa8241de11b99ecae…> > > <https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/caa8241de11b99ecae… > <https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/caa8241de11b99ecae…>> > > <https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/caa8241de11b99ecae… > <https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/caa8241de11b99ecae…> > > <https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/caa8241de11b99ecae… > <https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/caa8241de11b99ecae…>>> > > Â Â Â Â Â Â Â Â Â Maybe it's a bit too recent to be found in > official Pharo > Â Â Â Â Â Â Â Â Â distribution, but if you can live with > bleeding edge, > Â Â Â Â pick a > Â Â Â Â Â Â Â Â Â more recent VM here: > https://bintray.com/opensmalltalk/vm/cog/201710221351#files > <https://bintray.com/opensmalltalk/vm/cog/201710221351#files> > > <https://bintray.com/opensmalltalk/vm/cog/201710221351#files > <https://bintray.com/opensmalltalk/vm/cog/201710221351#files>> > > <https://bintray.com/opensmalltalk/vm/cog/201710221351#files > <https://bintray.com/opensmalltalk/vm/cog/201710221351#files> > > <https://bintray.com/opensmalltalk/vm/cog/201710221351#files > <https://bintray.com/opensmalltalk/vm/cog/201710221351#files>>> > Â Â Â Â Â Â Â Â Â (or maybe you can find one from the Pharo site?) > > > Â Â Â Â Â Â Â Â Â 2017-11-04 22:21 GMT+01:00 henry > <henry(a)callistohouse.club > Â Â Â Â Â Â Â Â Â <mailto:henry@callistohouse.club > <mailto:henry@callistohouse.club> > Â Â Â Â <mailto:henry@callistohouse.club > <mailto:henry@callistohouse.club>> > Â Â Â Â Â Â Â Â Â <mailto:henry@callistohouse.club > <mailto:henry@callistohouse.club> > Â Â Â Â <mailto:henry@callistohouse.club > <mailto:henry@callistohouse.club>>>>>: > > Â Â Â Â Â Â Â Â Â Â Â Â This is the advantage of in-image SSL > solution, > Â Â Â Â found in the > Â Â Â Â Â Â Â Â Â Â Â Â Cryptography repository: > > http://www.squeaksource.com/Cryptography.html > <http://www.squeaksource.com/Cryptography.html> > Â Â Â Â <http://www.squeaksource.com/Cryptography.html > <http://www.squeaksource.com/Cryptography.html>> > Â Â Â Â Â Â Â Â Â <http://www.squeaksource.com/Cryptography.html > <http://www.squeaksource.com/Cryptography.html> > Â Â Â Â <http://www.squeaksource.com/Cryptography.html > <http://www.squeaksource.com/Cryptography.html>>> > > <http://www.squeaksource.com/Cryptography.html > <http://www.squeaksource.com/Cryptography.html> > Â Â Â Â <http://www.squeaksource.com/Cryptography.html > <http://www.squeaksource.com/Cryptography.html>> > Â Â Â Â Â Â Â Â Â <http://www.squeaksource.com/Cryptography.html > <http://www.squeaksource.com/Cryptography.html> > Â Â Â Â <http://www.squeaksource.com/Cryptography.html > <http://www.squeaksource.com/Cryptography.html>>>> > > Â Â Â Â Â Â Â Â Â Â Â Â Sent from ProtonMail Mobile > > > Â Â Â Â Â Â Â Â Â Â Â Â On Fri, Nov 3, 2017 at 12:53, Raffaello > Giulietti > Â Â Â Â Â Â Â Â Â Â Â Â <raffaello.giulietti(a)lifeware.ch > <mailto:raffaello.giulietti@lifeware.ch> > Â Â Â Â <mailto:raffaello.giulietti@lifeware.ch > <mailto:raffaello.giulietti@lifeware.ch>> > Â Â Â Â Â Â Â Â Â <mailto:raffaello.giulietti@lifeware.ch > <mailto:raffaello.giulietti@lifeware.ch> > Â Â Â Â <mailto:raffaello.giulietti@lifeware.ch > <mailto:raffaello.giulietti@lifeware.ch>>> > Â Â Â Â Â Â Â Â Â Â Â Â <mailto:raffaello.giulietti@lifeware.ch > <mailto:raffaello.giulietti@lifeware.ch> > Â Â Â Â <mailto:raffaello.giulietti@lifeware.ch > <mailto:raffaello.giulietti@lifeware.ch>> > Â Â Â Â Â Â Â Â Â <mailto:raffaello.giulietti@lifeware.ch > <mailto:raffaello.giulietti@lifeware.ch> > Â Â Â Â <mailto:raffaello.giulietti@lifeware.ch > <mailto:raffaello.giulietti@lifeware.ch>>>>> wrote: > > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Hi, the SqueakSSL dll is not included > in the Pharo > Â Â Â Â Â Â Â Â Â Â Â 64bit/Win vm > Â Â Â Â Â Â Â Â Â Â Â Â Â Â distribution. I guess this has to do with > Â Â Â Â problems in > Â Â Â Â Â Â Â Â Â Â Â building it. > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Anybody knows where the difficulties lie? > Â Â Â Â Greetings > Â Â Â Â Â Â Â Â Â Â Â Raffaello > > > > > > > > > > > >

Nov. 6, 2017

Re: [Pharo-dev] [IMPORTANT] Is there a bug in Tonel with category:

by Ben Coman

Can this be dealt with by Quality Assistant? Special rules when in a particular group of classes? i.e. BaselineXXXXX cheers -ben On Mon, Nov 6, 2017 at 10:43 PM, Dale Henrichs < dale.henrichs(a)gemtalksystems.com> wrote: > ...also note that I have seen a number of baselines where symbols are used > in places where Strings are required ... of course with Pharo's > implementation of Symbol it is not practical to use asString nor type > checks - things that are not necessary in other Smalltalk implementations > ... In Metacello the only "legal" place to use a Symbol is for a symbolic > version ... > > Of course this is really only an issue for cross platform projects and the > issue shows up as a problem real fast ... it's just painful for the > uninitiated to debug ... > > Dale > > > > On 11/6/17 1:51 AM, stephan wrote: > >> On 05-11-17 22:05, Stephane Ducasse wrote: >> >>> I was working in cleaning the users of asLayoutFrame and when I commit I >>> see >>> >>> - #category : 'Morphic-Base-Layouts' >>> + #category : #Morphic-Base-Layouts >>> >>> but #category : #Morphic-Base-Layouts >>> is not a valid symbol. >>> >> >> In Metacello we use the quoted symbol form exactly because different >> smalltalks have different ideas of what a valid symbol is. >> >> Stephan >> >> >> >> > >

Nov. 6, 2017

Re: [Pharo-dev] [IMPORTANT] Is there a bug in Tonel with category:

by Nicolas Cellier

2017-11-06 17:23 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > > On 6 Nov 2017, at 17:13, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> > wrote: > > > > > > > > On 11/6/17 7:07 AM, Sven Van Caekenberghe wrote: > >> > >>> On 6 Nov 2017, at 15:43, Dale Henrichs <dale.henrichs@gemtalksystems. > com> wrote: > >>> > >>> of course with Pharo's implementation of Symbol it is not practical to > use asString nor type checks - things that are not necessary in other > Smalltalk implementations > >> How so ? > >> > >> What is the problem with Symbol>>#asString ? > > I am not going to go to every field in the api that is supposed to be a > String and add asString. There are too many places to worry about ... I > would prefer that Pharo be ANSI compliant:) > > > > It's not just Metacello. > > > > It's an annoying issue that has to be dealt with every time a Pharo > application is ported to another dialect of Smalltalk and an annoying > barrier for folks running on other dialects to move their application to > Pharo - in this case the bugs that are introduced by Pharo's behavior with > respect to Symbols can be very hard to diagnose -- > > > > Making things harder to share code between dialects is a bad thing for > Smalltalk overall -- just another reason for non-Smalltalk programmers to > question the whether they should use Smalltalk or not... > > > > And I don't need to hear about how Pharo is not Smalltalk:) > > > > Dale > > So there is nothing 'wrong', you just want Pharo to remain the same as > every other non-changing Smalltalk out there. > > From one perspective you are right, it makes some cross platform porting > in either direction harder. Seaside has many rules to help portability. Not > mixing Strings and Symbol is probably one of them. > > But you know very well that Pharo was started so that we would be able to > make changes, in any area or aspect of the system, without the burden of > backwards or cross platform compatibility, even if some of these changes > are taste based. > > And I happen to like the ability to mix and match Strings and Symbols (we > discussed about this before). > > Sven > > > > Note that it's not entirely Pharo's fault. #foo = 'foo' in Squeak too.

Nov. 6, 2017

Re: [Pharo-dev] [IMPORTANT] Is there a bug in Tonel with category:

by Sven Van Caekenberghe

> On 6 Nov 2017, at 17:13, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > > > > On 11/6/17 7:07 AM, Sven Van Caekenberghe wrote: >> >>> On 6 Nov 2017, at 15:43, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: >>> >>> of course with Pharo's implementation of Symbol it is not practical to use asString nor type checks - things that are not necessary in other Smalltalk implementations >> How so ? >> >> What is the problem with Symbol>>#asString ? > I am not going to go to every field in the api that is supposed to be a String and add asString. There are too many places to worry about ... I would prefer that Pharo be ANSI compliant:) > > It's not just Metacello. > > It's an annoying issue that has to be dealt with every time a Pharo application is ported to another dialect of Smalltalk and an annoying barrier for folks running on other dialects to move their application to Pharo - in this case the bugs that are introduced by Pharo's behavior with respect to Symbols can be very hard to diagnose -- > > Making things harder to share code between dialects is a bad thing for Smalltalk overall -- just another reason for non-Smalltalk programmers to question the whether they should use Smalltalk or not... > > And I don't need to hear about how Pharo is not Smalltalk:) > > Dale So there is nothing 'wrong', you just want Pharo to remain the same as every other non-changing Smalltalk out there. >From one perspective you are right, it makes some cross platform porting in either direction harder. Seaside has many rules to help portability. Not mixing Strings and Symbol is probably one of them. But you know very well that Pharo was started so that we would be able to make changes, in any area or aspect of the system, without the burden of backwards or cross platform compatibility, even if some of these changes are taste based. And I happen to like the ability to mix and match Strings and Symbols (we discussed about this before). Sven

Nov. 6, 2017

Re: [Pharo-dev] SqueakSSL on Pharo 64bit/Win

by Nicolas Cellier

No matter which step fails, the build is considered failed if return code differs from 0... 2017-11-06 15:23 GMT+01:00 Raffaello Giulietti < raffaello.giulietti(a)lifeware.ch>: > Hi Nicolas, > > seems that only the upload to the Pharo repo fails, not the building by > itself. > > But the cog_win64x64_pharo.stack.spur_201711061254.zip is not even on the > bintray repo. I would expect it at least there. Is that right? Just > wondering... > > Of course, I'll try to grab the SqueakSSL.dll from the squeak 64 bit/win > vm. > > > > > On 2017-11-06 15:05, Nicolas Cellier wrote: > >> Unfortunately, the VM is corectly built, but the script fails at deploy >> stage... >> https://ci.appveyor.com/project/OpenSmalltalk/vm/branch/Cog/ >> job/gx20b215gls5jq7w >> >> Uploading ./pharo-win-x86_64-201711061254-f819c8f.zip to >> pharo.files.org//appli/files.pharo.org/vm/pharo-spur64/win < >> http://pharo.files.org//appli/files.pharo.org/vm/pharo-spur64/win> >> Warning: Permanently added the RSA host key for IP address >> '193.51.193.142' to the list of known hosts. >> Uploading ./pharo-win-x86_64-201711061254-f819c8f.zip to >> pharo.files.org//appli/files.pharo.org/vm/pharo-spur64/win/latest.zip < >> http://pharo.files.org//appli/files.pharo.org/vm/pharo- >> spur64/win/latest.zip> >> scp: /appli/files.pharo.org/vm/pharo-spur64/win/latest.zip < >> http://files.pharo.org/vm/pharo-spur64/win/latest.zip>: Permission denied >> Command exited with code 1 >> >> At this stage, there's not much i can do. >> You'll have to ask to Pharo team to correct this problem. >> >> In the interim, I suggest you download the Squeak VM for Win64 and pick >> SqueakSSL.dll there... >> >> 2017-11-06 11:34 GMT+01:00 Raffaello Giulietti < >> raffaello.giulietti(a)lifeware.ch <mailto:raffaello.giulietti@lifeware.ch >> >>: >> >> Thanks Nicolas! >> >> >> >> On 2017-11-06 11:30, Nicolas Cellier wrote: >> >> Oh yes, you're right, >> the SqueakSLL could have been built but was not built in pharo... >> I just changed >> https://github.com/OpenSmalltalk/opensmalltalk-vm/edit/Cog/ >> build.win64x64/pharo.cog.spur/plugins.ext >> <https://github.com/OpenSmalltalk/opensmalltalk-vm/edit/Cog/ >> build.win64x64/pharo.cog.spur/plugins.ext> >> this should trigger another automated build and if all goes well >> you will have a new bintray artefact to test. >> >> 2017-11-06 10:21 GMT+01:00 Raffaello Giulietti >> <raffaello.giulietti(a)lifeware.ch >> <mailto:raffaello.giulietti@lifeware.ch> >> <mailto:raffaello.giulietti@lifeware.ch >> >> <mailto:raffaello.giulietti@lifeware.ch>>>: >> >> >> Hi Nicolas, >> >> I tried both the vm found at the location you mention (dated >> 2017-10-22): >> >> https://bintray.com/opensmalltalk/vm/download_file?file_ >> path=cog_win64x64_pharo.cog.spur_201710221351.zip >> <https://bintray.com/opensmalltalk/vm/download_file?file_ >> path=cog_win64x64_pharo.cog.spur_201710221351.zip> >> <https://bintray.com/opensmall >> talk/vm/download_file?file_path=cog_win64x64_pharo.cog. >> spur_201710221351.zip >> <https://bintray.com/opensmalltalk/vm/download_file?file_ >> path=cog_win64x64_pharo.cog.spur_201710221351.zip>> >> >> and the "official" latest vm on the Pharo site (dated >> 2017-11-01) >> >> http://files.pharo.org/vm/pharo-spur64/win/pharo-win-x86_64- >> 201711010928-e14fbab.zip >> <http://files.pharo.org/vm/pharo-spur64/win/pharo-win-x86_ >> 64-201711010928-e14fbab.zip> >> <http://files.pharo.org/vm/pha >> ro-spur64/win/pharo-win-x86_64-201711010928-e14fbab.zip >> <http://files.pharo.org/vm/pharo-spur64/win/pharo-win-x86_ >> 64-201711010928-e14fbab.zip>> >> >> >> >> Neither of them contains the SqueakSSL.dll and, in fact, in >> both >> cases I get an exception when using Gofer to download >> Roassal2, >> using the latest 60519 image: >> >> Gofer it >> smalltalkhubUser: 'ObjectProfile' project: 'Roassal2'; >> configurationOf: 'Roassal2'; >> loadDevelopment >> >> This works on Pharo 32 bit/Win, where SquekSSL is present. >> >> >> >> >> >> >> >> >> On 2017-11-04 23:31, Nicolas Cellier wrote: >> >> Note that win64 SSL works at least since >> https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/baa >> 70862014d3bb510f2edf7465e857c645be0e4 >> <https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/ba >> a70862014d3bb510f2edf7465e857c645be0e4> >> <https://github.com/OpenSmallt >> alk/opensmalltalk-vm/commit/baa70862014d3bb510f2edf7465e857c645be0e4 >> <https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/ba >> a70862014d3bb510f2edf7465e857c645be0e4>> >> and >> https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/caa >> 8241de11b99ecaea5236b3d3e3c0d303c6eb4 >> <https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/ca >> a8241de11b99ecaea5236b3d3e3c0d303c6eb4> >> <https://github.com/OpenSmallt >> alk/opensmalltalk-vm/commit/caa8241de11b99ecaea5236b3d3e3c0d303c6eb4 >> <https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/ca >> a8241de11b99ecaea5236b3d3e3c0d303c6eb4>> >> >> Maybe it's a bit too recent to be found in official Pharo >> distribution, but if you can live with bleeding edge, >> pick a >> more recent VM here: >> https://bintray.com/opensmalltalk/vm/cog/201710221351#files >> <https://bintray.com/opensmalltalk/vm/cog/201710221351#files> >> <https://bintray.com/opensmall >> talk/vm/cog/201710221351#files >> <https://bintray.com/opensmalltalk/vm/cog/201710221351#files>> >> (or maybe you can find one from the Pharo site?) >> >> >> 2017-11-04 22:21 GMT+01:00 henry >> <henry(a)callistohouse.club >> <mailto:henry@callistohouse.club >> <mailto:henry@callistohouse.club> >> <mailto:henry@callistohouse.club >> <mailto:henry@callistohouse.club>>>>: >> >> This is the advantage of in-image SSL solution, >> found in the >> Cryptography repository: >> >> http://www.squeaksource.com/Cryptography.html >> <http://www.squeaksource.com/Cryptography.html> >> <http://www.squeaksource.com/Cryptography.html >> <http://www.squeaksource.com/Cryptography.html>> >> <http://www.squeaksource.com/Cryptography.html >> <http://www.squeaksource.com/Cryptography.html> >> <http://www.squeaksource.com/Cryptography.html >> <http://www.squeaksource.com/Cryptography.html>>> >> >> Sent from ProtonMail Mobile >> >> >> On Fri, Nov 3, 2017 at 12:53, Raffaello Giulietti >> <raffaello.giulietti(a)lifeware.ch >> <mailto:raffaello.giulietti@lifeware.ch> >> <mailto:raffaello.giulietti@lifeware.ch >> <mailto:raffaello.giulietti@lifeware.ch>> >> <mailto:raffaello.giulietti@lifeware.ch >> <mailto:raffaello.giulietti@lifeware.ch> >> <mailto:raffaello.giulietti@lifeware.ch >> <mailto:raffaello.giulietti@lifeware.ch>>>> wrote: >> >> Hi, the SqueakSSL dll is not included in the >> Pharo >> 64bit/Win vm >> distribution. I guess this has to do with >> problems in >> building it. >> Anybody knows where the difficulties lie? >> Greetings >> Raffaello >> >> >> >> >> >> >> >> >> >> > >

Nov. 6, 2017