November 2017 - Pharo-users

Re: [Pharo-users] Why is compile: breaking my image?

by Peter UhnÃ¡k

Hi, this is a bit more confusing than I originally thought. So let me elaborate (this is not part of Pharo I've dabbled in before...) (there's an issue 20212 for this) The problem is somewhere in SyntaxErrorDebugger and probably SyntaxErrorNotification. Normally (by normally I mean according to the implementation) when an syntax debugger is created, it is created in new process. However when I close the window without saving, the process is not terminated. Some one has decided that SyntaxErrorDebugger>>release was not good enough, so they've added a WindowClosed catch (in SyntaxErrorDebugger class>>buildMorphicViewOn: ) that in turn calls SyntaxErrorDebugger>>handleWindowClosed. That probably fixed whatever the author was trying to fix, but it broke overall. The expected behavior should be: 1) when a debugger window appears and I close it, the process should terminate -- it doesn't 2) when a debugger window appears and I enter a valid text and save it, 2.i) the process should terminate -- it doesn't 2.ii) the method should be compiled -- it compiles the original broken code So something like this can happen Something compile: '^^'. * enter some correct code, e.g. 'method ^ 1' * Something selectors "-> #(#method)" (Something>>#method) sourceCode "-> '^^'" I don't understand how this is even possible to have sourceCode that doesn't include the selector. 3) when a debugger window appears and I enter invalid code, then it should 2.a) either terminate the previous process and launch a new process containing the updated, but broken code 2.b) or not terminate and reuse the current process but display the new broken code right now it creates a new process, but doesn't terminate. Peter On Mon, Nov 13, 2017 at 9:42 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Can you share what was the original problem and how you fixed it? > > On Sat, Nov 11, 2017 at 4:44 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >> >> >> > On 11 Nov 2017, at 16:33, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> > >> > Never mind... I see now what is broken and I'll try to fix it (assuming >> my P7 image won't corrupt itself due to FreeType before I manage to push >> the changes... heh) >> >> You can now disable FreeType fonts and still use bitmapped Source Code >> fonts. >> >> > On Sat, Nov 11, 2017 at 3:43 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> > This applies to P61 (for some time) and P7. >> > >> > Object compile: '^'. >> > >> > Syntax Error popup -> close >> > >> > now you have two morphic UI processes running and World starts to get >> corrupted with artifacts around. (and it also in one case manage to >> actually corrupt the image to the point that I was no longer able to even >> launch it). >> > >> > Peter >> > >> >> >> > > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 >

Nov. 13, 2017

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

by Sean P. DeNigris

Stephane Ducasse-3 wrote > 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. What's broken? I use it all the time. Maybe something I fixed should be backported from my GH fork? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Nov. 13, 2017

Re: [Pharo-users] [Pharo-dev] Publishing a book with Pillar

by Julien

> Le 13 nov. 2017 Ã 21:01, Stephane Ducasse <stepharo.self(a)gmail.com> a Ã©crit : > > Hi guys > > we are working on pillar and we will probably release a new alph version soon. > I'm updating the doc. But I found that the doc I was writing can help > some of you. > > Julien is written a nice booklet on USBdrivers and he told me that > this doc works super well on mac. > > Stef > <book.pdf> Thanks for your work on this beautiful project guys. :-) Julien

Nov. 13, 2017

Re: [Pharo-users] Why is compile: breaking my image?

by Guillermo Polito

Can you share what was the original problem and how you fixed it? On Sat, Nov 11, 2017 at 4:44 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > On 11 Nov 2017, at 16:33, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > > Never mind... I see now what is broken and I'll try to fix it (assuming > my P7 image won't corrupt itself due to FreeType before I manage to push > the changes... heh) > > You can now disable FreeType fonts and still use bitmapped Source Code > fonts. > > > On Sat, Nov 11, 2017 at 3:43 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > This applies to P61 (for some time) and P7. > > > > Object compile: '^'. > > > > Syntax Error popup -> close > > > > now you have two morphic UI processes running and World starts to get > corrupted with artifacts around. (and it also in one case manage to > actually corrupt the image to the point that I was no longer able to even > launch it). > > > > Peter > > > > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Nov. 13, 2017

Re: [Pharo-users] Peeking at a stream

by Guillermo Polito

Yeah, I understand. The thing is that we will remove in the near future MultiByteFileStream. And not all streams have conceptually a position. Today there was a mail from Sven about that. On Mon, Nov 13, 2017 at 2:48 PM, Prof. Andrew P. Black <black(a)cs.pdx.edu> wrote: > > > On 2 Nov 2017, at 10:10 , Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > > > My first hunch is that you don't want to change PositionableStream. > Because it works on collections and files (because of inheritance). But not > on other kind of streams that are not part of the hierarchy, such as > sockets. And we are cleaning that part. > > > > Instead, some time ago Sven produced a really nice hierarchy of stream > decorators. Check the package: > > > > Zinc-Character-Encoding-Core > > > > There you have > > > > ZnBufferedReadStream > > > > That implements buffering in an orthogonal way. Maybe it makes more > sense to put such method there? > > > > I wanted this to be something light-weight. I really donât want to have > to wrap my stream in a decorator before peeking ahead. > > Because Iâm doing this in SmaCC, I implemented #explore: (thatâs the name > I chose) in SmaCCLineNumberStream. But I think that the general solution > is to put this method in a Trait, so that it can be combined into any > stream, whether or not that stream inherits from PositionableStream. There > are probably other methods that could go in such a trait too. > > Actually, the idea of resetting a stream to a prior position is much less > general, and easier to implement, then general positionability. Over the > weekend I posted an issue that discusses positioning a MultiButeFileStream > â thatâs a good example. > > Here is my implementation â really simple. > > ``` > explore: aBlock > "evaluate aBlock with this stream as argument. When done, reset > my position to the current position." > > | savedPosition | > savedPosition := self position. > [ ^ aBlock value: self ] ensure: [ self position: savedPosition ] > ``` > > Andrew > > > > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Nov. 13, 2017

Re: [Pharo-users] Stream API

by Guillermo Polito

Thanks Sven, we should take that list of selectors and make a document or Lint rules on them. On Mon, Nov 13, 2017 at 9:08 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > On Mon, Nov 13, 2017 at 8:27 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > 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). > > Yes really nice :) > > And Guille started to use them and we are slowly rewriting all the > stream internal users to use Zn and after we will be free. > > > > 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. > > > YES YES YES and celebrate. I could never understand anything. My brain > is too limited for these kind of games :) > > > > > The contract of a stream should be much, much simpler than it is today. > > Fully agree. > > > > > 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 > >> > > > > > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Nov. 13, 2017

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

by Juraj Kubelka

Hi Sven, thank you for the fix! I understand that #allowNil is about reading, while #writeNil: is about writing. I use the same mapping for the reader and writer. This is why I spotted the case. Thanks! Juraj > On Nov 13, 2017, at 16:30, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > 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 Stephane Ducasse

On Mon, Nov 13, 2017 at 8:27 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > 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). Yes really nice :) And Guille started to use them and we are slowly rewriting all the stream internal users to use Zn and after we will be free. > 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. YES YES YES and celebrate. I could never understand anything. My brain is too limited for these kind of games :) > The contract of a stream should be much, much simpler than it is today. Fully agree. > > 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

Thriving on chaos

by Stephan Eggermont

Op 13-11-2017 om 02:55 schreef ÐÐ¸ÐºÐµÐ½ÑÐ¸Ð¹ ÐÐ¾ÑÐ°Ð¿Ð¾Ð²: > I'm very lazy and i like to read rich manuals more than to > investigate complex code. I think it is much more natural when you > don't need to study the whole system before you can do simple things. The "thriving on chaos" kind of development with fast change we do in Pharo is not likely to develop many artifacts like that. The parts that stabilize develop them, and the ones that are in flux don't. An issue might be that Pharo is slightly different in so many ways, and you are confronted with much more change than you are used to with VW. It takes time to adapt to a situation where continuous learning is needed and wanted, and the time where VW changed so fast is long over. > 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. 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. Another difference is that in Pharo the development is transparent, you see all the new ideas and prototypes, good and bad. That is totally different from closed source development, where you only get a chance to react to things that are more or less finished. On the one hand that means you waste time on things that turn out to be bad ideas, on the other hand you have actual influence on how Pharo develops. > 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 assumption of dumb questions. We assume we fail to document well enough. The questions were good enough and for some parts our answers are not yet good enough. We improve and continue to improve. The way we are now able to quickly create booklets about a subject is much better than what we did before. > 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. One of our fallacies is wanting to do things better than existing systems. That sometimes results in parts that are in development for too long, and having to live with parts that are not finished. Also, open source frameworks are often only finished to the level needed for the original author's application. > 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). I find the Pharo community is open to fixing bugs and answering questions. Open source definitely has the property that you are much more likely to get help if you show that you have tried to find a solution. Being less close to a large concentration of Pharo developers I've found it very useful to show what I have been playing with and where I'm running into. > 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. Pharo is improving at a speed with which I'm certain that will happen. It will be sooner if you make Pharo yours, and help us get there. Stephan

Nov. 13, 2017

Publishing a book with Pillar

by Stephane Ducasse

Hi guys we are working on pillar and we will probably release a new alph version soon. I'm updating the doc. But I found that the doc I was writing can help some of you. Julien is written a nice booklet on USBdrivers and he told me that this doc works super well on mac. Stef

Nov. 13, 2017