September 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Issue validation seems really strange

by Yuriy Tymchuk

Sorry again for breaking it. Fix awaits here: https://pharo.fogbugz.com/f/cases/19075/SmallLint-tests-failing-after-update > On 10 Sep 2016, at 23:29, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > I broke it. The fix is on the way > >> On 10 Sep 2016, at 10:45, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: >> >> Hi >> >> this is strange because the last issue validation (ilke adding class comments) got such validation output. >> The errors looks totally strange. >> Stef >> >> <jdmdociclbjogfnb.png> >> >

Sept. 10, 2016

Re: [Pharo-dev] Issue validation seems really strange

by Yuriy Tymchuk

I broke it. The fix is on the way > On 10 Sep 2016, at 10:45, stepharo <stepharo(a)free.fr> wrote: > > Hi > > this is strange because the last issue validation (ilke adding class comments) got such validation output. > The errors looks totally strange. > Stef > > <jdmdociclbjogfnb.png> >

Sept. 10, 2016

About Year not knowing exact daysInMonth

by stepharo

Hi I started to write a little utility to generate bills. And I need to know the number of days in a month and I was surprised that (Month month: 2) daysInMonth returns 28 because we do not know :) So I thought that I was obviously wrong and I should use (Year year: 2016) daysInMonth > "#(31 28 31 30 31 30 31 31 30 31 30 31)" :( When I look at the implementation this is clear that it is wrong daysInMonths ^ Date daysInMonth totally not aware of the year. I think that daysInMonths should use DateAndTime creating a dummy date for each month and using asMonth daysInMonth (DateAndTime year: 2016 month: 2 day: 3) asMonth daysInMonth > 29 Year >> daysInMonth: aMonthNumber "Returns the days in month for a given month" <expr: #(#(#Year #year: 2016) #daysInMonth: 2) result: 29> ^ (DateAndTime year: self year month: aMonthNumber) asMonth daysInMonth I extended the class with some more practical methods. What do you think? I should push them to pharo? I was surprised that the library was not that good. Stef

Sept. 10, 2016

Re: [Pharo-dev] PharoJS ESUG 2016 Demo files

by philippe.back＠highoctane.be

But http://blackpagedigital.com/snowglobe/ may be able to. Craig told me they did something for a Pharo image at ESUG. Phil Le 10 sept. 2016 17:20, "Hilaire" <hilaire(a)drgeo.eu> a Ã©crit : > > Hi, > > Can PharoJS be used to turn Dr. Geo as JavasScript appliation running in > the browser? > > Thanks > > Hilaire > > Le 09/09/2016 Ã 10:51, Noury Bouraqadi a Ã©crit : > > Hi, > > > > The Pharo 4.0 image + related files used in the PharoJS ESUG 2016 demo > > are now available for download at > > https://pharojs.github.io/faq.html#demoEsug2016 > > > > Best, > > Noury > > > > -- > Dr. Geo > http://drgeo.eu > >

Sept. 10, 2016

Re: [Pharo-dev] About file printOn: method

by stepharo

o this is what I was trying to get done. >> I do not know if what you propose (which can be better than what I was >> planning) requires to change fileSystem, my goal was not to change for >> now but just make sure that I can get cheaply file to print themselves >> into kind of objects I can manipulate again. >> >> Now if what you propose is better, then first we should introduce a >> logic to handle :file :memory >> >> And I'm not against so plese push it but this is outside of my little >> goal for now. > You're right. Your solution is much simpler - therefore I'd go with > your solution for now. > >> would be nice. Push this idea. Once the community agrees then we can >> easily extend the printOn: behavior. > I'll try to work through the FS code and see if I can get the stuff > I'm thinking about implemented. Please :) I like the idea of URI for everything > >> Did you watch the excellent talk of marcus at ESUG? >> Because I think incrementally > One of the first videos/slidedecks I watched - the title made me > curious. My key take-away is that it's better to implement the > cheap/simple/non-perfect enhancement now than never (too late) the > perfect one. :)

Sept. 10, 2016

Re: [Pharo-dev] PharoJS ESUG 2016 Demo files

by stepharo

Hi Hilaire I do not think so. Stef Le 10/9/16 Ã 17:19, Hilaire a Ã©crit : > Hi, > > Can PharoJS be used to turn Dr. Geo as JavasScript appliation running in > the browser? > > Thanks > > Hilaire > > Le 09/09/2016 Ã 10:51, Noury Bouraqadi a Ã©crit : >> Hi, >> >> The Pharo 4.0 image + related files used in the PharoJS ESUG 2016 demo >> are now available for download at >> https://pharojs.github.io/faq.html#demoEsug2016 >> >> Best, >> Noury >>

Sept. 10, 2016

linux vm-build

by Nicolai Hess

current linux vm build is broken. the platform display plugin now expects a ioScreenScaleFactor function that isn't defined for vm-display-X11 and vm-display-null and some defines in sq.h had changed from DragLeave to SqDragLeave (and the same for all other drag events). And maybe more, but fixing the above changes, I was at least able to build a vm nicolai

Sept. 10, 2016

Re: [Pharo-dev] About file printOn: method

by Udo Schneider

On 10/09/16 10:52, stepharo wrote: > So this is what I was trying to get done. > I do not know if what you propose (which can be better than what I was > planning) requires to change fileSystem, my goal was not to change for > now but just make sure that I can get cheaply file to print themselves > into kind of objects I can manipulate again. > > Now if what you propose is better, then first we should introduce a > logic to handle :file :memory > > And I'm not against so plese push it but this is outside of my little > goal for now. You're right. Your solution is much simpler - therefore I'd go with your solution for now. > would be nice. Push this idea. Once the community agrees then we can > easily extend the printOn: behavior. I'll try to work through the FS code and see if I can get the stuff I'm thinking about implemented. > Did you watch the excellent talk of marcus at ESUG? > Because I think incrementally One of the first videos/slidedecks I watched - the title made me curious. My key take-away is that it's better to implement the cheap/simple/non-perfect enhancement now than never (too late) the perfect one.

Sept. 10, 2016

Re: [Pharo-dev] PharoJS ESUG 2016 Demo files

by Hilaire

Hi, Can PharoJS be used to turn Dr. Geo as JavasScript appliation running in the browser? Thanks Hilaire Le 09/09/2016 Ã 10:51, Noury Bouraqadi a Ã©crit : > Hi, > > The Pharo 4.0 image + related files used in the PharoJS ESUG 2016 demo > are now available for download at > https://pharojs.github.io/faq.html#demoEsug2016 > > Best, > Noury > -- Dr. Geo http://drgeo.eu

Sept. 10, 2016

Re: [Pharo-dev] About file printOn: method

by stepharo

Le 9/9/16 Ã 20:57, Udo Schneider a Ã©crit : > Hi Stef, > > once upon in time :-) I picked up the notion that #printString > "should" return a string which (when executed) results in the printed > object. Yes we agree on this one. Now do you understand what are self evaluating objects? The idea there is that {10@20 . 33@44} printString returns {10@20 . 33@44} and not just anOrderedCollection (10 #@ 20 .....) So this is what I was trying to get done. I do not know if what you propose (which can be better than what I was planning) requires to change fileSystem, my goal was not to change for now but just make sure that I can get cheaply file to print themselves into kind of objects I can manipulate again. Now if what you propose is better, then first we should introduce a logic to handle :file :memory And I'm not against so plese push it but this is outside of my little goal for now. > Whereras #displayString is "nicer" for the user. Not quite sure if > this still applies though. But in this regard what about something like > > fr1 := FileSystem disk root / 'folder' / 'file.txt'. > fr2 := FileSystem memory root / 'folder' / 'file.txt'. > > fr1 printString. "FileSystem // 'file:///folder/file.txt'" > fr2 printString. "FileSystem // 'memory:///folder/file.txt'" > > fr1 displayString. "'file:///folder/file.txt'" > fr2 displayString. "'memory:///folder/file.txt'" > > For FileReferences which use a FileSystem with a configured Store > those settings could be added to the URL as host/query. E.g. for a > WebDav FileReference: > > #printString > "FileSystem // 'webdav://uid:pwd@host/folder/file.txt&usePatch=false'" > > #displayString > "'webdav://uid:pwd@host/folder/file.txt'" would be nice. Push this idea. Once the community agrees then we can easily extend the printOn: behavior. Did you watch the excellent talk of marcus at ESUG? Because I think incrementally > > CU, > > Udo > > > On 09/09/16 20:34, stepharo wrote: >> Hi Udo >> >> Thanks for the suggestion. It means that the printOn: should really >> involve the FieSystem and this is probably right. >> Now the point of the printOn: vs the displayString is that we can get >> back an object and right now we get a string :) >> Your URI suggestion should be applied to the displayString or the >> asFileReference should understand it. >> I added your feedback to the entry. >> >> Stef >> >> Le 9/9/16 Ã 20:19, Udo Schneider a Ã©crit : >>> I'm a bit biased on this. IMHO this simplification in the #printString >>> (which I quite like BTW!) is only applicable to Files in >>> DiskFileSystem. >>> >>> If you have a FileReference on a non disk filesystem (e.g. >>> >>> fr1 := FileSystem memory root / 'folder' / 'test.txt'. >>> "memory:///folder/test.txt" >>> >>> on use this simplified #printString you'll end up with >>> >>> '/folder/test.txt' asFileReference. >>> >>> This might be confusing as this does not mention the filesystem. So >>> you might end up creating a new instance via >>> >>> fr2 := '/folder/test.txt' asFileReference. >>> >>> which is not equal to the original fileRef: >>> >>> fr1 = fr2 "false" >>> >>> As I do like the #printString simplification ... why not simply adopt >>> a URI style scheme for FileReferences. This would allow encoding the >>> filesystem type (e.g. file://, memory://, zip://, s3://) including >>> parameters like host if needed and of course the path. >>> >>> CU, >>> >>> Udo >>> >>> >>> >>> On 04/09/16 09:47, stepharo wrote: >>>> It is raining and I will do it :) >>>> >>>> >>>> stef >>>> >>>> >>>> Le 4/9/16 Ã 02:38, monty a Ã©crit : >>>>> +1 >>>>> >>>>>> Sent: Saturday, September 03, 2016 at 10:39 AM >>>>>> From: stepharo <stepharo(a)free.fr> >>>>>> To: "Pharo Development List" >>>>>> <pharo-dev(a)lists.pharo.org> >>>>>> Subject: [Pharo-dev] About file printOn: method >>>>>> >>>>>> Hi >>>>>> >>>>>> >>>>>> I will implement the following because this is too annoying. >>>>>> >>>>>> currently >>>>>> >>>>>> 'tmp/foo.txt' asFileReference >>>>>> > >>>>>> File @ tmp/foo.txt >>>>>> >>>>>> and it would be much much better to get back >>>>>> 'tmp/foo.txt' asFileReference >>>>>> >>>>>> So that we can get >>>>>> { 'tmp/foo.txt' asFileReference } >>>>>> > { 'tmp/foo.txt' asFileReference } >>>>>> >>>>>> and not >>>>>> "an Array(File @ tmp/foo.txt)" >>>>>> >>>>>> >>>>>> In addition we should turn the current printOn: method into a >>>>>> displayString method so that >>>>>> a list of fileReference can be well display with File @ tmp/foo.txt >>>>>> for >>>>>> example >>>>>> >>>>>> >>>>>> https://pharo.fogbugz.com/f/cases/18956 >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >>> >> >> >> > > > >

Sept. 10, 2016