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

Re: [Pharo-dev] Fwd: Subscription Form to FogBugz

by Ben Coman

On Thu, Jun 30, 2016 at 2:40 AM, Tomas Saez Binelli <tomas.saezbin(a)gmail.com> wrote: > Hi everybody! > > I was trying to create an account on Fogbugz during a Sprint using the link > posted here: > > https://pharo.fogbugz.com/ > > But after filling the form and submiting it, i received the following > message: > > "Incorrect password or username" > > This is a little bit strange because i was not able to finish the > registration and create an account. > > Sending this email to make the error public. > > > Bye! > Tomas > Thanks for the report Tomas. I think I've seen this a long time ago, maybe your account was created but something went wrong with setting the password. As a work around, see if you can find a password reset button. cheers -ben

June 29, 2016

Apology: Re: Having comments for pragma?

by Jan Vrany

Stef, all,Â the post below was written by me, not by Stef as it looks. Due to some funny bug, my email client messed up with headers when I saved unfinished mail to "Drafts" and then come back to it later. Time to change email client.Â I'm very sorry for the confusion this caused.Â Jan On Wed, 2016-06-29 at 11:21 +0100, stepharo wrote: > > > On Tue, Jun 28, 2016 at 8:53 PM, stepharo <stepharo(a)free.fr> wrote: > > When I implemented annotation support I was initially thinking the > > same - let's create an instance of CoolAnnotationClass when the > > code is accepted > > and then one can add arbitrary code to his CoolAnnotationClass. I > > quickly realized this is a (very) bad idea. Or, to be precise, it > > is a bad idea given the > > environment. So I'd be very careful.. > > can you explain your statement? > > Let me try, this is tricky for me as I'm not good at explaining :-)Â > > The problems pop out when one need to load the code back. If > <coolish: 100> gets parsed and stored in > an annotation container as instance of class Coolish (at compilation > time), Â this means that you just > introduced a dependency from package of the method which contains the > annotation to the package of > Coolish class. This is not (or rather was not in my case) desirable, > because I need/want to annotate > methods in kernel with annotations for tools. Kernel should not > depend or tools - I believe we agree on > that :-) Note, that this is less of a problem for Java since Java > loads all code lazily, on demand and in a defined > way. I personally found it very nice Â - though it has some > (solvable?) issues when this lazy loading is used in SmalltalkishÂ > environment such as STX:LIBJAVA) > > You can indeed parse them and store them as raw data and convert them > on demand in reflective > API. Then, if the class is not available what to do? Return an > instance of generic Pragma?Â > Throw an error? When one starts to put an arbitrary code into the > annotation object itself it's either > processing Â code only access data Â or it somehow fiddles about the > annotation itself and/or (worse!) > about the method itself. The latter results in difficult to debug > problems as the time the code is executed > is undefined (if you use lazy instantiation to avoid dependency > problem). This may be fine withÂ > most Smalltalkers as there are other pieces of code that execute > randomly in an undefined order and stillÂ > very few complain :-) but I did not want to make things even worse.Â > For the former, mere data-accessing processing code, I don't see much > of a difference by putting itÂ > somwhere else. Follows the same logic as visitor, instead of putting > code to nodes, you put them > to extra visitor class.Â > > Eliot's design elegantly avoid these problems (the same way Java does > :-) by simply having one defined > structure which keeps the logical type of the annotation as data (the > selector of the message send). > It has other problems, but not the one above.Â > > Not sure if it makes sense, but I did my best :-) I'm not saying it's > not solvable and you cannot have > class per annotation type, but it is not **that** easy to get it > right. This is my experience over the years.Â > > HTH, Jan > > > > > Stef > > > > > > > > Jan > > > > P.S.: As for "which always forced me to hate Java": I found myself > > a very enlightening to think carefully about why somebody else > > do things differently before I start to hate her/him. Besides, > > there's whole lot of things that Java guys got right... > > > > > >

June 29, 2016

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

by 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 <akgrant0710(a)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 <akgrant0710(a)gmail.com> wrote: >> > >> > Hi All, >> > >> > UDBCSQLite3Statement>>at:putDateTime: currently writes date and times >> > using DateAndTime's default print string, i.e. >> > YYYY-MM-DDTHH:MM:SS.mmmmmm+hh:ss >> > >> > SQLite3 doesn't support timezones, and expects text formatted date/times >> > to be: >> > >> > YYYY-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: YYYY-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 / 1000000) 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 > >

June 29, 2016

Re: [Pharo-dev] Fwd: Subscription Form to FogBugz

by Esteban Lorenzano

seems to be having a problemâ¦ I will check it, thanks for report. Esteban > On 29 Jun 2016, at 20:40, Tomas Saez Binelli <tomas.saezbin(a)gmail.com> wrote: > > Hi everybody! > > I was trying to create an account on Fogbugz during a Sprint using the link posted here: > > https://pharo.fogbugz.com/ <https://pharo.fogbugz.com/> > > But after filling the form and submiting it, i received the following message: > > "Incorrect password or username" > > This is a little bit strange because i was not able to finish the registration and create an account. > > Sending this email to make the error public. > > > Bye! > Tomas > > <Captura.PNG>

June 29, 2016

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

by Alistair Grant

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 <akgrant0710(a)gmail.com> wrote: > > > > Hi All, > > > > UDBCSQLite3Statement>>at:putDateTime: currently writes date and times > > using DateAndTime's default print string, i.e. > > YYYY-MM-DDTHH:MM:SS.mmmmmm+hh:ss > > > > SQLite3 doesn't support timezones, and expects text formatted date/times > > to be: > > > > YYYY-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: YYYY-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 / 1000000) 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

June 29, 2016

Fwd: Subscription Form to FogBugz

by Tomas Saez Binelli

Hi everybody! I was trying to create an account on Fogbugz during a Sprint using the link posted here: https://pharo.fogbugz.com/ But after filling the form and submiting it, i received the following message: "Incorrect password or username" This is a little bit strange because i was not able to finish the registration and create an account. Sending this email to make the error public. Bye! Tomas

June 29, 2016

Re: [Pharo-dev] [squeak-dev] The .changes file should be bound to a single image

by Max Leske

> On 29 Jun 2016, at 14:45, David T. Lewis <lewis(a)mail.msen.com> wrote: > > Max, > > Confirming on Linux and Squeak. See below. > > On Wed, Jun 29, 2016 at 08:53:12AM +0200, Max Leske wrote: >> >>> On 29 Jun 2016, at 02:06, David T. Lewis <lewis(a)mail.msen.com> wrote: >>> >>> On Tue, Jun 28, 2016 at 04:47:00PM -0500, Chris Muller wrote: >>>> >>>> On Tue, Jun 28, 2016 at 5:04 AM, Max Leske <maxleske(a)gmail.com> wrote: >>>>> Hi, >>>>> >>>>> Opening the same image twice works fine as long as no writes to the .changes file occur. When both images write to the .changes file however it will be broken for both because the offsets for the changes are wrong. This can lead to lost data and predominantly to invalid method source code, which is a pain with Monticello. >>>>> >>>>> I suggest that we implement a kind of lock mechanism to ensure that only one image (the first one opened) can write to the .changes file. >>>>> >>> >>> If the offsets are wrong in this scenario, it's a bug in the image. The >>> image is supposed to seek to the end of the changes file before writing >>> the next chunk. While this sounds horrible in theory, in practice it works >>> remarkably well, and I have been happily surprised at how reliable it >>> is after many years of using and abusing the feature. That is a very >>> good thing. >>> >>> Adding a lock to prevent the scenario would be bad, because it would >>> surely break a number of other legitimate use cases. >>> >>> >>>>> >>>>> I???ve opened an issue for Pharo here: https://pharo.fogbugz.com/f/cases/18635/The-changes-file-should-be-bound-to… >>>>> >>>> >>>> >>>> I have several applications which launch multiple copies of the same >>>> image for multicore processing. The images do their work, commit it >>>> to database, then exit themselves without saving. Its a great >>>> feature. >> >> Doing work is not the problem. Modifying source code is the problem. >> >>> >>> That is consistent with my experience. I remember expecting horrible >>> things to happen if I had two images sharing a changes file, but nothing >>> bad ever happened. It just works. >>> >>>> >>>> I know OSProcess, when combined with CommandShell, has a RemoteTask >>>> which allows efficient forking of the image (via Linux copy-on-write >>>> memory sharing) and so a solution like what happens in Windows is not >>>> really good. >>> >>> My assumption with RemoteTask was that someone doing complex or long-running >>> jobs would more or less know what they were doing, and would have the good >>> sense to stop writing to the changes file from a bunch of forked images. >>> But in actual practice, I have never seen a problem related to this. >>> It just works. >>> >>>> >>>> Instead of putting a pop-up in front of the user, perhaps one way to >>>> solve the problem would be to, upon image save, simply goes through >>>> all the changes since the last save and re-flushes them to the >>>> .changes file. >>>> >>>> That way, if someone does want to save the same image on top of >>>> themself, at least it would be whichever saved last "wins".... >>>> >>> >>> There must be a problem somewhere, otherwise Max would not be raising >>> the issue. So whatever combination of operating system and image is >>> having a problem, I would be inclined fix that. >> >> :) Thanks Dave! >> >>> >>> Windows cannot be a problem, because the operating system will not >>> permit you to open the changes file twice. The Unix/Linux systems that >>> I have used all work fine. >>> >>> Max, which operating system/VM/image are you using? Is this on a Mac? >> >> Mac OS X 10.11.5, >> Pharo 6 (60086) >> >>> >>> Dave >>> >>> >> >> I actually didn???t open the issue for myself but because of a student who ran into this. I???ve been in the same situation before but I???m an experienced user while students at the research group sometimes just spend a couple of weeks with Pharo and then such things are a real problem. >> >> Interestingly the issue is, as you already suggested, pretty hard to reproduce i.e., modifying arbitrary methods in both images did not show the symptoms I was looking for. >> >> Here???s a reproducible case (at least on my machine): >> >> 1. create a new method in both images: >> >> foo >> ^ nil >> >> 2. Modify it in one image: >> >> foo >> "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum." >> ^ nil + 1 >> >> 3. Modify it in the other image: >> >> foo >> ^ nil - 1 isEmpty ifTrue: [ "blah" nil ] >> > > Confirmed on Linux + Squeak. > > I did your test above using #forkSqueak so that I had two identical images > sharing the same changes file. In each image, I saved the #foo method. At > that point, the changes file conntained exactly what I would expect. > > I then did a save and exit from the child image, followed by a save and exit > from the original image. I can see that the changes from the child image are > now overwriting the changes from the original parent image. Since the > parent image is the one that was saved last, its #foo method now has > corrupted source. > > This is not a scenario that I have ever encountered, but I can see how > it might happen in a classroom setting. > > I can't look into this further right now, but it seems possible that the > problem happens only when saving the image, in which case we could force > the changes file to seek to end of file before doing the save. But we'll > need to do some more testing to make sure that this is the only scenario > in which it happens. > > Dave Great, thanks. In the scenario I described I did not save either image. Of course, without saving the problem will not exist as soon as you start the image anew (the old pointers are still valid and new content will be written to the end). The problem does exhibit itself without saving though. Since this is not anything critical, donât put too much effort into it. Iâll have time in a couple of weeks to look at it in detail and then, once we understand the problem, we can discuss possible solutions. Cheers, Max > > > >> In my case saving in step three produces a syntax error when the source is loaded from file again. I don???t really have a clue as to what the underlying issue is, but I suspect it may have to do with comments and a particular situation in which the position is not being correctly updated before or after writing. >> >> >> I agree with Chris that locks may be problematic, it just seemed like the simplest obvious solution (although of course it gets complicated when an image crashes and doesn???t clean up the lock???). >> >> Cheers, >> Max

June 29, 2016

Re: [Pharo-dev] Catalog Browser timed out

by Esteban Lorenzano

restored > On 29 Jun 2016, at 14:49, Ben Coman <btc(a)openinworld.com> wrote: > > When opening the Catalog Browser I am getting connection timed out. > Tested from two different Images: > * a fresh generator.image from running newImage.sh of the pharo-vm. > * my usual PharoLauncher image > > cheers -ben >

June 29, 2016

Catalog Browser timed out

by Ben Coman

When opening the Catalog Browser I am getting connection timed out. Tested from two different Images: * a fresh generator.image from running newImage.sh of the pharo-vm. * my usual PharoLauncher image cheers -ben

June 29, 2016

Re: [Pharo-dev] [squeak-dev] The .changes file should be bound to a single image

by David T. Lewis

Max, Confirming on Linux and Squeak. See below. On Wed, Jun 29, 2016 at 08:53:12AM +0200, Max Leske wrote: > > > On 29 Jun 2016, at 02:06, David T. Lewis <lewis(a)mail.msen.com> wrote: > > > > On Tue, Jun 28, 2016 at 04:47:00PM -0500, Chris Muller wrote: > >> > >> On Tue, Jun 28, 2016 at 5:04 AM, Max Leske <maxleske(a)gmail.com> wrote: > >>> Hi, > >>> > >>> Opening the same image twice works fine as long as no writes to the .changes file occur. When both images write to the .changes file however it will be broken for both because the offsets for the changes are wrong. This can lead to lost data and predominantly to invalid method source code, which is a pain with Monticello. > >>> > >>> I suggest that we implement a kind of lock mechanism to ensure that only one image (the first one opened) can write to the .changes file. > >>> > > > > If the offsets are wrong in this scenario, it's a bug in the image. The > > image is supposed to seek to the end of the changes file before writing > > the next chunk. While this sounds horrible in theory, in practice it works > > remarkably well, and I have been happily surprised at how reliable it > > is after many years of using and abusing the feature. That is a very > > good thing. > > > > Adding a lock to prevent the scenario would be bad, because it would > > surely break a number of other legitimate use cases. > > > > > >>> > >>> I???ve opened an issue for Pharo here: https://pharo.fogbugz.com/f/cases/18635/The-changes-file-should-be-bound-to… > >>> > >> > >> > >> I have several applications which launch multiple copies of the same > >> image for multicore processing. The images do their work, commit it > >> to database, then exit themselves without saving. Its a great > >> feature. > > Doing work is not the problem. Modifying source code is the problem. > > > > > That is consistent with my experience. I remember expecting horrible > > things to happen if I had two images sharing a changes file, but nothing > > bad ever happened. It just works. > > > >> > >> I know OSProcess, when combined with CommandShell, has a RemoteTask > >> which allows efficient forking of the image (via Linux copy-on-write > >> memory sharing) and so a solution like what happens in Windows is not > >> really good. > > > > My assumption with RemoteTask was that someone doing complex or long-running > > jobs would more or less know what they were doing, and would have the good > > sense to stop writing to the changes file from a bunch of forked images. > > But in actual practice, I have never seen a problem related to this. > > It just works. > > > >> > >> Instead of putting a pop-up in front of the user, perhaps one way to > >> solve the problem would be to, upon image save, simply goes through > >> all the changes since the last save and re-flushes them to the > >> .changes file. > >> > >> That way, if someone does want to save the same image on top of > >> themself, at least it would be whichever saved last "wins".... > >> > > > > There must be a problem somewhere, otherwise Max would not be raising > > the issue. So whatever combination of operating system and image is > > having a problem, I would be inclined fix that. > > :) Thanks Dave! > > > > > Windows cannot be a problem, because the operating system will not > > permit you to open the changes file twice. The Unix/Linux systems that > > I have used all work fine. > > > > Max, which operating system/VM/image are you using? Is this on a Mac? > > Mac OS X 10.11.5, > Pharo 6 (60086) > > > > > Dave > > > > > > I actually didn???t open the issue for myself but because of a student who ran into this. I???ve been in the same situation before but I???m an experienced user while students at the research group sometimes just spend a couple of weeks with Pharo and then such things are a real problem. > > Interestingly the issue is, as you already suggested, pretty hard to reproduce i.e., modifying arbitrary methods in both images did not show the symptoms I was looking for. > > Here???s a reproducible case (at least on my machine): > > 1. create a new method in both images: > > foo > ^ nil > > 2. Modify it in one image: > > foo > "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum." > ^ nil + 1 > > 3. Modify it in the other image: > > foo > ^ nil - 1 isEmpty ifTrue: [ "blah" nil ] > Confirmed on Linux + Squeak. I did your test above using #forkSqueak so that I had two identical images sharing the same changes file. In each image, I saved the #foo method. At that point, the changes file conntained exactly what I would expect. I then did a save and exit from the child image, followed by a save and exit from the original image. I can see that the changes from the child image are now overwriting the changes from the original parent image. Since the parent image is the one that was saved last, its #foo method now has corrupted source. This is not a scenario that I have ever encountered, but I can see how it might happen in a classroom setting. I can't look into this further right now, but it seems possible that the problem happens only when saving the image, in which case we could force the changes file to seek to end of file before doing the save. But we'll need to do some more testing to make sure that this is the only scenario in which it happens. Dave > In my case saving in step three produces a syntax error when the source is loaded from file again. I don???t really have a clue as to what the underlying issue is, but I suspect it may have to do with comments and a particular situation in which the position is not being correctly updated before or after writing. > > > I agree with Chris that locks may be problematic, it just seemed like the simplest obvious solution (although of course it gets complicated when an image crashes and doesn???t clean up the lock???). > > Cheers, > Max > > > >

June 29, 2016