June 2018 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Pharo 7 streams API

by Sven Van Caekenberghe

Peter, > On 23 Jun 2018, at 15:39, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Hi, > > I'm starting to familiarize myself with new streams, and one thing I've noticed is the removal of #lineEndConvention (which I use all the time). > > So a statement like this > > aFile writeStreamDo: [ :stream | > stream lineEndConvention: #lf. > stream << '...' > ]. > > has to be written like so > > aFile writeStreamDo: [ :rawStream | |stream| > stream := (ZnNewLineWriterStream on: rawStream) forLf. > stream << '...' > ]. > > which feels very messy because I am mixing writing with the configuration. And I don't even take account for buffered/encoded decorators. Plus it increases the incidental complexity -- I need another variable, and I can accidentally write to the wrong stream, etc. > > Would a method like #writeStream:do: (or #writeStreamTransform:do:) make sense? E.g. > > aFile writeStreamTransform: [ :stream | (ZnNewLineWriterStream on: stream) ] do: [ :stream | > stream << '...' > ] > > To separate the composition from the usage? > > Thanks, > Peter The goals of the 'new' (they have existed for quite a while) streams is to go from single big complex do all classes and replace that with a composition of much simpler single purpose classes. Another goal is to reduce the API so that it becomes easier to create new stream classes. Of course, a consequence is that you need composition to get the functionality you want. But I think you understand the tradeoff. If the mixing of configuration/setup with writing/reading bothers you, then I would suggest using two methods. One that does only the writing/reading assuming a limited API, and another that does the configuration/setup, using composition. Note that the streams that you get already are a composition (most often a BinaryFileStream wrapped in a Buffered stream wrapped in a Encoding/Decoding stream). EOL translation is not a standard part of that. But there is quite some system code that does uses EOL translation. Sven

June 23, 2018

Re: [Pharo-users] Strange Result - OmniBase bug or Date feature?

by Alistair Grant

Hi Peter, On Sat, 23 Jun 2018 at 17:47, PBKResearch <peter(a)pbkresearch.co.uk> wrote: > > Hello All > > > > I am experimenting with the version of OmniBase which Esteban Lorenzano posted a few days ago. With corrections posted by Matias Moretto, who is working on the same track, I have got the first five tests all green. On the sixth test, OmniBaseTest>>#testEquality, I have run into a strange failure. I donât know whether it shows that OmniBase is not recovering data correctly, or whether it is a feature of the way Date is implemented in Pharo. (I still have Dolphin 6 on my machine, including OmniBase, and there the same test passes.) > > > > The test simply constructs a collection of various types of object, stores the whole collection on the database, retrieves it and compares each retrieved element with the corresponding element of the original collection. One element is obtained by evaluating âDate todayâ, and that is the one that fails. The test failure description is: âGot 23 June 2018 instead of 23 June 2018.â Using the inspector, I can see that the retrieved date differs from the original in that the instvar âstartâ has a Julian Day Number which is one greater, but seconds as zero instead of 82800 and an offset of zero instead of 1:00:00. In fact 82800 seconds is 23 hours, so all these add up to the same start time, just differently represented. > > > > To get round the failure, I changed the constructor of the test collection to use âDate today printStringâ, which of course meant it worked perfectly. My worry is whether in some other context the change of the innards of the object might have an adverse effect. I donât understand why the Date constructor represents the start of today as 23 hours after 1 a.m. yesterday. Is the change something OmniBase has done in storing and retrieving, or is it due to the way the Date is reconstructed? A Date in Pharo is a 24 hour period and thus the timezone is important, e.g. the start of 23 Jun in London is not the same as 23 Jun in Melbourne. If you want to compare the date using day / month / year and not as a 24 hour period, try using #equals: instead of #=. HTH, Alistair

June 23, 2018

Strange Result - OmniBase bug or Date feature?

by PBKResearch

Retransmit with additional information: All tests with Windows 10 with all recent updates Hello All I am experimenting with the version of OmniBase which Esteban Lorenzano posted a few days ago. With corrections posted by Matias Moretto, who is working on the same track, I have got the first five tests all green. On the sixth test, OmniBaseTest>>#testEquality, I have run into a strange failure. I don't know whether it shows that OmniBase is not recovering data correctly, or whether it is a feature of the way Date is implemented in Pharo. (I still have Dolphin 6 on my machine, including OmniBase, and there the same test passes.) The test simply constructs a collection of various types of object, stores the whole collection on the database, retrieves it and compares each retrieved element with the corresponding element of the original collection. One element is obtained by evaluating 'Date today', and that is the one that fails. The test failure description is: 'Got 23 June 2018 instead of 23 June 2018.' Using the inspector, I can see that the retrieved date differs from the original in that the instvar 'start' has a Julian Day Number which is one greater, but seconds as zero instead of 82800 and an offset of zero instead of 1:00:00. In fact 82800 seconds is 23 hours, so all these add up to the same start time, just differently represented. To get round the failure, I changed the constructor of the test collection to use 'Date today printString', which of course meant it worked perfectly. My worry is whether in some other context the change of the innards of the object might have an adverse effect. I don't understand why the Date constructor represents the start of today as 23 hours after 1 a.m. yesterday. Is the change something OmniBase has done in storing and retrieving, or is it due to the way the Date is reconstructed? Just for fun, I used Fuel to serialize and re-materialize Date today; it did not make any changes. Does this reinforce Todd's suggestion that OmniBase is not reliable, or is it just a quirk? Any ideas gratefully received Peter Kenny

June 23, 2018

Strange Result - OmniBase bug or Date feature?

by PBKResearch

Hello All I am experimenting with the version of OmniBase which Esteban Lorenzano posted a few days ago. With corrections posted by Matias Moretto, who is working on the same track, I have got the first five tests all green. On the sixth test, OmniBaseTest>>#testEquality, I have run into a strange failure. I don't know whether it shows that OmniBase is not recovering data correctly, or whether it is a feature of the way Date is implemented in Pharo. (I still have Dolphin 6 on my machine, including OmniBase, and there the same test passes.) The test simply constructs a collection of various types of object, stores the whole collection on the database, retrieves it and compares each retrieved element with the corresponding element of the original collection. One element is obtained by evaluating 'Date today', and that is the one that fails. The test failure description is: 'Got 23 June 2018 instead of 23 June 2018.' Using the inspector, I can see that the retrieved date differs from the original in that the instvar 'start' has a Julian Day Number which is one greater, but seconds as zero instead of 82800 and an offset of zero instead of 1:00:00. In fact 82800 seconds is 23 hours, so all these add up to the same start time, just differently represented. To get round the failure, I changed the constructor of the test collection to use 'Date today printString', which of course meant it worked perfectly. My worry is whether in some other context the change of the innards of the object might have an adverse effect. I don't understand why the Date constructor represents the start of today as 23 hours after 1 a.m. yesterday. Is the change something OmniBase has done in storing and retrieving, or is it due to the way the Date is reconstructed? Just for fun, I used Fuel to serialize and re-materialize Date today; it did not make any changes. Does this reinforce Todd's suggestion that OmniBase is not reliable, or is it just a quirk? Any ideas gratefully received Peter Kenny

June 23, 2018

Re: [Pharo-users] Workflow aka Aare status?

by CÃ©drick BÃ©ler

>> >> >>> itâs was mainly about the removal of Omnibase dependancies)â¦ and >>> generating Seaside web UI (through Magritte) we do not have that anymore. > > It was not really a choice. Netstyle submitted it that way I guess. And what we did was mainly to remove remaining trace of these dependencies (and understand). > > Still I find this is better to have something more generic with different persistance choice (voyage ?) and Magritte as it was also only seaside. > > The problem is that now the package by itself is not really usable as the web interface + logging was very central. > > My 2 cents, > > Cedrick > > > >> >> I'm curious - what was the motivation to remove those two dependencies? >> >> >> >> ----- >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>

June 23, 2018

Re: [Pharo-users] Workflow aka Aare status?

by CÃ©drick BÃ©ler

> Le 23 juin 2018 Ã 15:50, Sean P. DeNigris <sean(a)clipperadams.com> a Ã©crit : > > cedreek wrote >> itâs was mainly about the removal of Omnibase dependancies)â¦ and >> generating Seaside web UI (through Magritte) we do not have that anymore. It was not really a choice. Netstyle submitted it that way I guess. Still I find this is better to have something more generic with different persistance choice (voyage ?) and Magritte as it was also only seaside. The problem is that now the package by itself is not really usable as the web interface + logging was very central. My 2 cents, Cedrick > > I'm curious - what was the motivation to remove those two dependencies? > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

June 23, 2018

Re: [Pharo-users] Workflow aka Aare status?

by Sean P. DeNigris

cedreek wrote > itâs was mainly about the removal of Omnibase dependancies)â¦ and > generating Seaside web UI (through Magritte) we do not have that anymore. I'm curious - what was the motivation to remove those two dependencies? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

June 23, 2018

Pharo 7 streams API

by Peter UhnÃ¡k

Hi, I'm starting to familiarize myself with new streams, and one thing I've noticed is the removal of #lineEndConvention (which I use all the time). So a statement like this aFile writeStreamDo: [ :stream | stream lineEndConvention: #lf. stream << '...' ]. has to be written like so aFile writeStreamDo: [ :rawStream | |stream| stream := (ZnNewLineWriterStream on: rawStream) forLf. stream << '...' ]. which feels very messy because I am mixing writing with the configuration. And I don't even take account for buffered/encoded decorators. Plus it increases the incidental complexity -- I need another variable, and I can accidentally write to the wrong stream, etc. Would a method like #writeStream:do: (or #writeStreamTransform:do:) make sense? E.g. aFile writeStreamTransform: [ :stream | (ZnNewLineWriterStream on: stream) ] do: [ :stream | stream << '...' ] To separate the composition from the usage? Thanks, Peter

June 23, 2018

Re: [Pharo-users] Smalltalk Programming Competition

by Tim Mackinnon

Nice - now youâve really got to work out the details of the competition and how your going to judge it. Sent from my iPhone > On 23 Jun 2018, at 11:07, horrido <horrido.hobbies(a)gmail.com> wrote: > > Alan Kay contributed to my campaign!!!!! This is so frickin' amazing! > > Can we spell S-T-A-R P-O-W-E-R, boys and girls? > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

June 23, 2018

Re: [Pharo-users] [ANN] GNU Dr. Geo release 18.06

by Hilaire

As a matter of accuracy, it is more active essays paradigm[1]. Hilaire [1] http://www.vpri.org/pdf/tr2009002_active_essays.pdf Le 23/06/2018 Ã 08:17, Hilaire a Ã©critÂ : > They call it Dynabook in the old time... Not yet there 40 years later, > we are damn slow. -- Dr. Geo http://drgeo.eu

June 23, 2018