November 2017 - Pharo-users

Re: [Pharo-users] RB refactoring rewrite variable to a symbol

by Peter UhnÃ¡k

Thanks Thierry, I'll try it out! re werner: ... the other question was about the tool, because it was a very nice tool to write and tweak rewrite rules On Sat, Nov 11, 2017 at 7:32 PM, werner kassens <wkassens(a)libello.com> wrote: > Hi Peter, > i assume from your question "RewriteTool maintained?" that you want to > make a RBTransformationRule, right? if yes, i once had a similar problem > and overwrote only #checkMethod: > checkMethod: aMethod > | arg | > arg := aMethod argumentNames first asString. > self initialize. > self rewriteRule > replace: > '| ``@temporaries1 | > `.@Statement' > with: > ('| ``@temporaries1 | > {1} blahblah ifTrue: [ ^ {1} adaptToNumber: self andSend: > #{2}]. > `.@Statement' > format: {arg. aMethod selector}). > ^ super checkMethod: aMethod > not too elegant, but it works. you could strip ":" from the method > selector and do something similar. > werner > > On 11/11/2017 05:17 PM, Peter UhnÃ¡k wrote: > > Hi, > > > > how can I rewrite a(n instance) variable to a symbol? > > > > E.g. > > > > [IN] > > something: aSomething > > something := aSomething > > > > [OUT] > > something: aSomething > > self write: aSomething into: #something > > > > > > I can capute the input just fine... ``@var := ``@arg > > but I have no idea how to convert the var into a symbol (or string). > > > > Thanks, > > Peter > > > > >

Nov. 13, 2017

Re: [Pharo-users] NeoJSON. Allowing null or an object

by Sven Van Caekenberghe

Juraj, Check out: === Name: Neo-JSON-Core-SvenVanCaekenberghe.46 Author: SvenVanCaekenberghe Time: 13 November 2017, 6:59:13.995868 pm UUID: f412799a-431a-0d00-850e-5c3c05ce5378 Ancestors: Neo-JSON-Core-SvenVanCaekenberghe.45 Fix the NeoJSONWriter>>#writeNil: true option by adding a short circuit to NeoJSONWriter>>nextPut:as: (as reported by Juraj Kubelka) Add #testRectanglePointsWithNil === Name: Neo-JSON-Tests-SvenVanCaekenberghe.44 Author: SvenVanCaekenberghe Time: 13 November 2017, 6:59:37.365898 pm UUID: 35acdd9b-431a-0d00-850f-878405ce5378 Ancestors: Neo-JSON-Tests-SvenVanCaekenberghe.43 Fix the NeoJSONWriter>>#writeNil: true option by adding a short circuit to NeoJSONWriter>>nextPut:as: (as reported by Juraj Kubelka) Add #testRectanglePointsWithNil === These should fix your last case. I used your example in the new unit test. Note that #allowNil on a mapper is about reading, not writing. HTH, Sven > On 13 Nov 2017, at 17:10, Juraj Kubelka <juraj.kubelka(a)icloud.com> wrote: > > Hi, > > I have just found the answer for the reader: > > -=-=-=- > rectangleJson := '{ > "origin" : null, > "corner" : null > }'. > > (NeoJSONReader on: rectangleJson readStream) > mapInstVarsFor: Point; > for: Point do: [ :mapping | > mapping allowNil ]; > for: Rectangle do: [ :mapping | > (mapping mapInstVar: #origin) valueSchema: Point. > (mapping mapInstVar: #corner) valueSchema: Point ]; > nextAs: Rectangle. > -=-=-=- > > I have an impression that there is a bug in the writer. While the following example works: > > -=-=-=- > String streamContents: [ :stream | > (NeoJSONWriter on: stream) > for: Point do: [ :mapping | > mapping mapAllInstVars. > mapping allowNil ]; > for: Rectangle do: [ :mapping | > (mapping mapInstVar: #origin) valueSchema: Point. > (mapping mapInstVar: #corner) valueSchema: Point ]; > nextPut: Rectangle new ]. > -=-=-=- > > the following example does not work: > > -=-=-=- > String streamContents: [ :stream | > (NeoJSONWriter on: stream) > for: Point do: [ :mapping | > mapping mapAllInstVars. > mapping allowNil ]; > for: Rectangle do: [ :mapping | > (mapping mapInstVar: #origin) valueSchema: Point. > (mapping mapInstVar: #corner) valueSchema: Point ]; > writeNil: true; > nextPut: Rectangle new ]. > -=-=-=- > > What do you think? > Juraj > >> On Nov 13, 2017, at 12:50, Juraj Kubelka <juraj.kubelka(a)icloud.com> wrote: >> >> Hi, >> >> Please, how should I modify the mapping to be able to parse the following example? >> >> -=-=-=- >> rectangleJson := '{ >> "origin" : null, >> "corner" : null >> }'. >> >> (NeoJSONReader on: rectangleJson readStream) >> mapInstVarsFor: Point; >> for: Rectangle do: [ :mapping | >> (mapping mapInstVar: #origin) valueSchema: Point. >> (mapping mapInstVar: #corner) valueSchema: Point ]; >> nextAs: Rectangle. >> -=-=-=- >> >> I receive from a server JSON messages including null values. >> Can we say use Point value schema or null? How? >> >> In the documentation I can see the example: >> >> -=-=-=- >> String streamContents: [ :stream | >> (NeoJSONWriter on: stream) >> mapAllInstVarsFor: Point; >> writeNil: true; >> nextPut: Point new ]. >> -=-=-=- >> that produces {"x":null,"y":null} >> >> But I do not see how to apply this for the following example: >> -=-=-=- >> String streamContents: [ :stream | >> (NeoJSONWriter on: stream) >> mapAllInstVarsFor: Point; >> for: Rectangle do: [ :mapping | >> (mapping mapInstVar: #origin) valueSchema: Point. >> (mapping mapInstVar: #corner) valueSchema: Point ]; >> writeNil: true; >> nextPut: Rectangle new ]. >> -=-=-=- >> >> Thanks, >> Juraj >> >> >

Nov. 13, 2017

Re: [Pharo-users] Stream API

by Sven Van Caekenberghe

The idea is to have much simpler streams which can be composed to get more sophisticated behaviour. The most primitive streams should be binary read or write streams, like a raw file or network connection. To add a character encoding/decoding you wrap them in a ZnCharacterReadStream or ZnCharacterWriteStream (these use the newer, cleaner ZnCharacterEncoders). If you want buffering, you wrap a ZnBufferedReadStream or ZnBufferedWriteStream around them. And there are some other examples in the system too. Have a look at BinaryFileStream and ZdcSocketStream. Simply put, MultiByteFileStream and MultiByteBinaryOrTextStream must die, because they try to be everything at once and are impossible to change. The contract of a stream should be much, much simpler than it is today. For writing that means #nextPut: #nextPutAll: #next:putAll: #next:putAll:startingAt: the 3 last ones can be written in terms of of the first one, but the last one is key because it can be the most efficient. And maybe also #flush #close Some helpers for character writing are #space #tab #cr #crlf #lf Maybe #newline #<< is a handy method too. For reading that means #atEnd #next #next: #next:into: #next:into:startingAt: #nextInto: #peek #skip: #upToEnd #upTo: #readInto:startingAt:count: Again, they can all be written in terms of #next, but #readInto:startingAt:count: is the core, efficient one. Note that #peek allows a one character lookahead, which should be sufficient for almost all parsing needs. #close is also a necessary operation, #peekFor: a handy one, #nextLine is popular too. There is a discussion about positioning (#position , #position: and related) but these cannot be supported _in general_ by the kind of streams described above. If you absolutely need these, read #upToEnd and use a regular ReadStream (over a fixed collection). The collection based classic Streams should always remain in the system, they are too handy. But have you seen for example, #nextInt32 on PositionableStream ? Good luck with that when the the underlying collection is anything other than bytes. All this being said, there is no one, single correct answer. But if we all try to simplify what we expect of streams (use a more limited API), we'll be more nimble to make implementation changes later on. Sven > On 13 Nov 2017, at 19:58, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Hi Evan > > I think that we will use the ZnStreams. > If we use Xtreams we will transform their API because some messages > are not really good. > Stef > > On Mon, Nov 13, 2017 at 7:54 PM, Evan Donahue <emdonahu(a)gmail.com> wrote: >> I've heard mention once or twice on this list and in some release notes of >> what sounded like possible coming changes to the stream API. Could anyone >> point me to any concrete details about that? I haven't been able to dig >> anything up myself by searching. I'm about to write something that I'd like >> to be polymorphic with the stream API, but if that's about to change, I'd >> like to plan ahead. >> >> Thanks, >> Evan >

Nov. 13, 2017

Re: [Pharo-users] PharoLauncher directories

by Stephan Eggermont

Op 8-11-2017 om 15:56 schreef stephan: > I run into all kinds of issues with the directory structure used by the > new PharoLauncher. When I copy an image with the launcher, how can I synchronize the Iceberg repositories again? Do I just need to copy the original directory containing them? Is that something we want to automate? Stephan

Nov. 13, 2017

Re: [Pharo-users] Stream API

by Andrew Glynn

Xtreams has very good performance, but the APIâs are messy. I havenât compared the performance of ZnStreams, but it shouldnât be radically different. From: Stephane Ducasse Sent: Monday, November 13, 2017 1:59 PM To: Any question about pharo is welcome Subject: Re: [Pharo-users] Stream API Hi Evan I think that we will use the ZnStreams. If we use Xtreams we will transform their API because some messages are not really good. Stef On Mon, Nov 13, 2017 at 7:54 PM, Evan Donahue <emdonahu(a)gmail.com> wrote: > I've heard mention once or twice on this list and in some release notes of > what sounded like possible coming changes to the stream API. Could anyone > point me to any concrete details about that? I haven't been able to dig > anything up myself by searching. I'm about to write something that I'd like > to be polymorphic with the stream API, but if that's about to change, I'd > like to plan ahead. > > Thanks, > Evan

Nov. 13, 2017

Re: [Pharo-users] Pharo-users Digest, Vol 55, Issue 102

by Stephane Ducasse

On Mon, Nov 13, 2017 at 2:55 AM, ÐÐ¸ÐºÐµÐ½ÑÐ¸Ð¹ ÐÐ¾ÑÐ°Ð¿Ð¾Ð² <vikenti.potapov(a)gmail.com> wrote: > > Thanks Stef, also thank all of you for your support. It is very important to me and shows that Pharo is really in progress. > I didn't ever complained - i just asked simple questions on topics i don't know. And i get lot's of answers to make some decisions. I understand where to get information and what are the prospects of using Pharo. > > I came to Pharo looking for appropreate Smalltalk implementation after Cincom denied access to its PUL version of VW. I found Pharo as the most advanced but it also has its disadvantages. > > My project is a desktop GUI application with some hacks with saving data to\from image on-the-fly and lots of GUI dialogs + complex custom GUI control. It is a kind of personal data\information manager. Did you look at the Spec book? > > I'm very lazy and i like to read rich manuals more than to investigate complex code. Me too. But nobody gets paid to write documentation not even me. I think it is much more natural when you don't need to study the whole system before you can do simple things. For example, i don't want to waste lots of time to understand what is the difference between bloc and spec, i want to read few paragraphs of manual and look into some class comments, and than do the task. > Bloc is not for you. So i think you made a great progress in this direction with Spec - the manual is very clear and allows developing UI with minimal efforts - just to read some abstracts from manual. > You see we wrote this manual for FREE. I will also update it for FREE. > > But in some areas i need to ask somebody who knows much more than i do. And i don't think there could be "dumb questions", but a _lack_of_information_. Also, when something is evident to one - it could be not so evident to another person. That is why i ask such simple things. > There is no problem. Just think that Pharo is open source and that it is our COMMON GOODS. We all share it and we ALL try to make it better. > Also i became accustomed to the situation when platform implements some basic stuff like i wrote earlier (UI tools, i18n, deployment, etc) and it was not evident to me that such modern system as Pharo cannot do it, so i asked about it. Sure now you can improve Pharo too. > I have seen that Pharo is powerful system but i need to decide what to do: > 1) create some personal solution based on different answers above. Lots of code investigations, coding and debugging (fixing existed bugs that are not on pharo roadmap). If you have many forms you may have a look at magritte the Morph builder does not work anymore but may be it is worth fixing it. > 2) wait until some release of Pharo fix bugs with non-latin paths, implement minimal level of integrated with UI framework i18n and deployment\packaging of applications. It does not work like that. If you do not open a bug entry with a clear problem description why people not having this problem should fix it? We are making sure that Pharo can be used for people to deliver product and make money but we have also our agenda and duties. Now the best things that you can do is help yourself and we will help you but do not expect that magically we fix the problems you have. Look for example Alistair spotted some problems in FileSystem and he fixed them and we integrated them for the benefits of EVERYBODY. > > Every software developer tries to find the simplest solution for his task. Yes but this is not the point. Pharo can shape your future and Pharo is not a close product. Now we can all contribute. Just start to open a bug entry with a test. This is the first step if you want that we spend time on your problem. > > I apologized if i said something wrong, i really didn't want to hurt somebody's feelings. No do not worry. I have a strong skin :) Stef > > Vikenti. > >> >> We are focused on deployment but not the same way. >> We are the first system that bootstrap a core and can load >> dependencies on this core. >> We have a dependency analyser that is really advanced since it can >> check that you have message that are not in extension >> of packages that you use. >> In January I hope that we will start packaging Applications (versus >> packaging code), so that people can deploy >> desktop applications more easily. >> >> Now if people like vikenti wants our support. They should learn how to >> engage a discussion with us and not >> just complain :) >> >> Stef >> >

Nov. 13, 2017

Re: [Pharo-users] FileReference>>#moveTo: across filesystems

by Stephane Ducasse

This is great to see FileSystem improving. On Mon, Nov 13, 2017 at 7:11 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Claudio, > > On 13 November 2017 at 18:49, Claudio Corrodi <corrodi(a)inf.unibe.ch> wrote: >> Hi all, >> >> Manuel Leuenberger and I ran into an issue with the FileReference>>#moveTo: >> method last week. On my system, I have "/" and "/home" in two different >> partitions/file systems. If I do something like the following, Pharo >> complains with a PrimitiveFailed signal: >> >> '/tmp/aFile.txt' asFileReference moveTo: '/home/claudio/aFile.txt' >> asFileReference >> >> I do not know how this is implemented exactly, but assume that the "rename" >> syscall is used (on Linux systems, that is), which does not work across file >> systems. The issue does not arise if I moveTo: inside the same filesystem. >> >> Is this expected behaviour? It is not obvious (to me) that >> FileReference>>#moveTo: requires source and target to be on the same >> filesystem. It would therefore make more sense to me if there were a >> fallback that copies and deletes if two filesystems are involved (much like >> "mv" behaves). >> >> What do you think? >> >> Cheers, >> Claudio > > This issue was fixed some time ago. I'm having trouble finding the > fogbugz issue, but it is definitely fixed in Pharo 7. Would you > please let me know which build of Pharo you are using, and take a look > at FileSystem>>move:to: and compare it to (minus the formatting > changes :-)): > > move: sourcePath to: destination > "Move the file /directory referenced as sourcePath to the destination > referred as destPath. > If there is no file at sourcePath, raise FileDoesNotExist. > If destPath is a file, raise FileExists. > If destPath is a directory, move the sourcePath in to the directory" > > | fullDestination | > > destination isFile ifTrue: [ FileExists signalWith: destination ]. > destination isDirectory > ifTrue: [ fullDestination := destination / sourcePath basename ] > ifFalse: [ fullDestination := destination ]. > self = destination fileSystem ifTrue: > [ > "Ideally we would test whether the source and destination are on the > same filesystem from the OSs perspective. > Since we can't do that, just try rename, and if that fails, copy and delete." > [ self rename: sourcePath to: fullDestination resolve path ] > on: Error > do: [ :error | self copyAndDelete: sourcePath to: fullDestination ]. > ] ifFalse: > [ self copyAndDelete: sourcePath to: fullDestination ]. > ^fullDestination > > > Cheers, > Alistair >

Nov. 13, 2017

Re: [Pharo-users] Stream API

by Stephane Ducasse

Hi Evan I think that we will use the ZnStreams. If we use Xtreams we will transform their API because some messages are not really good. Stef On Mon, Nov 13, 2017 at 7:54 PM, Evan Donahue <emdonahu(a)gmail.com> wrote: > I've heard mention once or twice on this list and in some release notes of > what sounded like possible coming changes to the stream API. Could anyone > point me to any concrete details about that? I haven't been able to dig > anything up myself by searching. I'm about to write something that I'd like > to be polymorphic with the stream API, but if that's about to change, I'd > like to plan ahead. > > Thanks, > Evan

Nov. 13, 2017

Stream API

by Evan Donahue

I've heard mention once or twice on this list and in some release notes of what sounded like possible coming changes to the stream API. Could anyone point me to any concrete details about that? I haven't been able to dig anything up myself by searching. I'm about to write something that I'd like to be polymorphic with the stream API, but if that's about to change, I'd like to plan ahead. Thanks, Evan

Nov. 13, 2017

Re: [Pharo-users] FileReference>>#moveTo: across filesystems

by Alistair Grant

Hi Claudio, On 13 November 2017 at 18:49, Claudio Corrodi <corrodi(a)inf.unibe.ch> wrote: > Hi all, > > Manuel Leuenberger and I ran into an issue with the FileReference>>#moveTo: > method last week. On my system, I have "/" and "/home" in two different > partitions/file systems. If I do something like the following, Pharo > complains with a PrimitiveFailed signal: > > '/tmp/aFile.txt' asFileReference moveTo: '/home/claudio/aFile.txt' > asFileReference > > I do not know how this is implemented exactly, but assume that the "rename" > syscall is used (on Linux systems, that is), which does not work across file > systems. The issue does not arise if I moveTo: inside the same filesystem. > > Is this expected behaviour? It is not obvious (to me) that > FileReference>>#moveTo: requires source and target to be on the same > filesystem. It would therefore make more sense to me if there were a > fallback that copies and deletes if two filesystems are involved (much like > "mv" behaves). > > What do you think? > > Cheers, > Claudio This issue was fixed some time ago. I'm having trouble finding the fogbugz issue, but it is definitely fixed in Pharo 7. Would you please let me know which build of Pharo you are using, and take a look at FileSystem>>move:to: and compare it to (minus the formatting changes :-)): move: sourcePath to: destination "Move the file /directory referenced as sourcePath to the destination referred as destPath. If there is no file at sourcePath, raise FileDoesNotExist. If destPath is a file, raise FileExists. If destPath is a directory, move the sourcePath in to the directory" | fullDestination | destination isFile ifTrue: [ FileExists signalWith: destination ]. destination isDirectory ifTrue: [ fullDestination := destination / sourcePath basename ] ifFalse: [ fullDestination := destination ]. self = destination fileSystem ifTrue: [ "Ideally we would test whether the source and destination are on the same filesystem from the OSs perspective. Since we can't do that, just try rename, and if that fails, copy and delete." [ self rename: sourcePath to: fullDestination resolve path ] on: Error do: [ :error | self copyAndDelete: sourcePath to: fullDestination ]. ] ifFalse: [ self copyAndDelete: sourcePath to: fullDestination ]. ^fullDestination Cheers, Alistair

Nov. 13, 2017