December 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Text Indentation in Pharo editor

by Esteban Lorenzano

> On 8 Dec 2017, at 15:40, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > I would love to have Ctrl E and Ctrl A. > And yes we should not be different for the sake of it. > For the moment the reason is simple: we are full of work and even more. > > FYI: I'm starting at regular crash of the VM and regular superbad > behavior of the debugger (like hundred of debuggers, like spawing many > process) > there is a really bad problem there. > > Setf > > On Fri, Dec 8, 2017 at 10:52 AM, Ben Coman <btc(a)openinworld.com> wrote: >> >> >> On 8 December 2017 at 11:37, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >>> >>> Torsten Bergmann wrote >>>> so we do it with different shortcuts than regular editors >>> >>> I wonder if it makes sense to allow the standard shortcut. The current one >>> is a bit like playing twister ;) >> >> >> We should be different if there is a good reason, >> but where possible (especially on UI interface) we should align with the >> majority. +1000 this is my work motto, and what Iâm trying to do with my work on Pharo every day :) and of course, lot of work is still needed. >> I feel this case is the latter. agreed. Esteban >> >> cheers -ben >> >> >

Dec. 11, 2017

Re: [Pharo-dev] create snapshots out of github based packages

by Stephan Eggermont

Op 10-12-2017 om 15:44 schreef Cyril Ferlicot: > On dim. 10 dÃ©c. 2017 at 15:07, Nicolai Hess <nicolaihess(a)gmail.com wrote: >> And I don't mean 1 or 2 thousand files. >> Loading bloc for example creates over 20.000 files. >> >> This is damn slow on windows. > > This is one of the reasons Esteban created Tonel I think. With Tonel > there is 1 file par class instead of 1 file per method. Once it will be > really stable, moving projects to Tonel should speed up things on Windows. Indeed. An even larger problem is the write amplification: Minimium disk file size of 4KB means a slow down of a factor 20. 1 (primary) file per class and sorting the methods helps a lot. Doing that in a cross-platform compatible way so we can easier share source code needs some further refinement Stephan

Dec. 10, 2017

Re: [Pharo-dev] Weird ZnClient benchmarking result

by Norbert Hartl

I like that kind of noise because these numbers are very informative. And they show that pharo can be used in heavy scenarios, too > Am 10.12.2017 um 19:14 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > @ Henrik > > Arg, arg, arg, yes of course. > I actually did think about that, but still did not look carefully enough !! > Really stupid of me. > > It is even worse because I wrote that code ... > > Now, the #printOn: of BenchmarkResult is much clearer, less confusing: > > ZnClient new in: [ :client | > [ client get: 'http://localhost:8080' ] benchFor: 5 seconds ]. > > a BenchmarkResult(14,732 iterations in 5 seconds. 2,946 per second) > > vs > > ZnClient new in: [ :client | > client loggingOff. > [ client get: 'http://localhost:8080' ] benchFor: 5 seconds ]. > > a BenchmarkResult(42 iterations in 5 seconds 88 milliseconds. 8.255 per second) > > Still the same issue with $, and $. in frequency, but the iteration count is crystal clear. > > The reason #bench works like that is backwards compatibility at the time we introduced that. > > @ Ben > > Yes, I should have looked at the other side as well, to confirm things actually happened as I imagined them (the did not). > > Thx and sorry for the noise. > > Sven > >> On 10 Dec 2017, at 18:00, Henrik-Nergaard <draagren(a)outlook.com> wrote: >> >> Hi Sven, >> >> What you are seeing is most likely a $, vs $. issue. >> See BenchmarkResult >>#printFrequenceOn: it uses both decimal and thousand >> separators. >> >> If i run this code: >> ----------------------------------------- >> | counter | >> counter := >> ZnClient new in: [ :client | >> client loggingOff. >> [ client get: 'http://localhost:8080'. counter ] bench >> ]. >> counter. >> ----------------------------------------- >> >> Then i get 9035 ('1,773 per second') when no inspector is open, and only 22 >> ('5.995 per second') when inspecting the logs. >> >> Best regards, >> Henrik >> >> >> >> >> >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >>

Dec. 10, 2017

Re: [Pharo-dev] How to get rid of empty XML nodes?

by Norbert Hartl

Sure it can get quite annoying. It would be good to have a switch to prevent the creation of whitespace-only nodes at parse time. Norbert > Am 10.12.2017 um 08:42 schrieb Stephane Ducasse <stepharo.self(a)gmail.com>: > > Norbert > > Should I say to the tool generating the XML that it is an idiot? Even > that I cannot. It is a tool I do not control. > I have no control about what I get. > Now why we cannot control that if people add a line return or not does > not matter? > Why I cannot be in charge of deciding? I take the risk of the > interpretation but now > the "standard" does not help me at all. It just tells me that is good for me. > > I implemented in the past "standards" like XMI to found that there > were bugs in the spec. > > At then end, each time I visit a node I have to check > > visitNodeWithElements: aNodeWithElements > | currentNode | > currentNode := OkStubNode new. > self cleanNode: aNodeWithElements. > aNodeWithElements hasChildren > ifTrue: [ | tokenNode | > self cleanNode: aNodeWithElements nodes first. > tokenNode := self visitElement: aNodeWithElements > nodes first. > self assert: tokenNode isToken. > currentNode addChild: tokenNode. > aNodeWithElements nodes allButFirst > do: [ :each | currentNode addChild: (self > visitNodeWithElements: each) ] ]. > ^ currentNode > > And I do not like to modify a structure while I'm visiting it. > > > cleanNode: aNodeWithElements > aNodeWithElements removeNodes: (aNodeWithElements nodes select: > [ :e | e isStringNode and: [ e isEmpty or: [ e isWhitespace ] ] ]) > > So I understand why people are going away from XML. > > Stef > >> On Fri, Dec 8, 2017 at 4:02 PM, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> >>> Am 08.12.2017 um 14:21 schrieb Stephane Ducasse <stepharo.self(a)gmail.com>: >>> >>> Hi monty >>> >>> >>>> On Fri, Dec 8, 2017 at 9:03 AM, monty <monty2(a)programmer.net> wrote: >>>> By "empty XML nodes," do you mean whitespace-only string nodes? >>> >>> Yes >>> >>>> Those are included because all in-element whitespace is assumed significant by the spec: https://www.w3.org/TR/xml/#sec-white-space >>> >>> I know. There was a discussion a while ago. I just lost a couple of >>> hours understanding that :( >>> >>> But this is a super super super annoying practices. >>> We had to test each nodes to see if it is a empty nodes so it makes >>> everything a lot more complex without real justification >>> beside the fact that these standardizers probably never implemented >>> some real cases. >>> This standard is a really out of reality from that perspective. >> >> Are you sure you do not oversimplify things? XML would be even more complex if these cases would be in the standard. It is not easy to decide if a whitespace is important or not. >> Where do this whitespaces in your case come from? Most probably because the XML is pretty printed. That is inserting whitespaces into the serialized text. So why not just stopping to pretty print and your problem is gone. >> >> Norbert >>> >>>> The exception is if the element is declared in the DTD as only having element children ("element content"): https://www.w3.org/TR/xml/#dt-elemcontent >>> >>> Well the XML files that I had (I did not choose XML because I would >>> have prefer JSON :) ), had no DTD :( >>> >>> So at the end of the day, this wonderful standard puts all the stress >>> and burden to people. >>> >>>> >>>> For example, if you declare an element like this: >>>> >>>> <!ELEMENT one (two,three*,four?)> >>>> >>>> Any whitespace around a "two," "three," or "four" element child of a "one" element is insignificant and ignored (unless #preservesIgnorableWhitespace: is true). Other parsers, like LibXML2 and Xerces, behave the same way. >>>> >>>> I'll see if I can come up with some easier way to deal with this, like an optional parser setting, new enumeration methods, or maybe a tree transformation. >>> >>> It would be A HUGE PLUS!!!!!!!!!!!!!!!!!! >>> >>> >>> Because reality is that people have XML files with just nodes and no >>> empty nodes and they are forced to >>> Let me know because I could try. >>> >>> I was showing how to use Pharo to import code to pharo learners and >>> this was a big drag. >>> >>> Stef >>> >>> >>> I tried to set some values in the parser but it did not work. >>> BTW I saw that the configuration logic forces to write the following >>> >>> | parser doc visitor | >>> parser := XMLDOMParser new >>> on: self xmlContents; >>> preservesIgnorableWhitespace: true. >>> >>> and not >>> >>> | parser doc visitor | >>> parser := XMLDOMParser new >>> preservesIgnorableWhitespace: true. >>> on: self xmlContents; >>> >>> >>>> >>>>> Sent: Tuesday, December 05, 2017 at 8:29 AM >>>>> From: "Stephane Ducasse" <stepharo.self(a)gmail.com> >>>>> To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >>>>> Subject: [Pharo-dev] How to get rid of empty XML nodes? >>>>> >>>>> )Hi >>>>> >>>>> we are manipulating an XML document and I would like to get rid of the >>>>> spurious empty string. >>>>> We saw that the gt panes are doing it. >>>>> >>>>> (aNodeWithElements isStringNode >>>>> and: [aNodeWithElements isEmpty >>>>> or: [aNodeWithElements isWhitespace]] >>>>> >>>>> Is there a way not to produce empty nodes? >>>>> Is there a simple way not to have to handle them >>>>> >>>>> Now each time we are dealing with a node with have to check. >>>>> >>>>> Stef >>>>> >>>>> >>>> >> > <Original-java.xml>

Dec. 10, 2017

About margin and rectangle

by Stephane Ducasse

Hi While harvesting the old change of Henrik on margins and the idea that Rectangle should not be used to express margins. I looked at expandBy: comment In fact I would like to make sure that that no rectangle is passed as argument and that we can deprecate asMargin from the Rectangle class (we can keep it but I would like to identify the callers). expandBy: delta "Answer a Rectangle that is outset from the receiver by delta. delta is a Rectangle, Point, or scalar." ^ delta asMargin expandRectangle: self So looked at all the senders of expandBy: and they look ok. I imagine that I should do the same for extendBy: Stef

Dec. 10, 2017

Re: [Pharo-dev] Weird ZnClient benchmarking result

by Sven Van Caekenberghe

@ Henrik Arg, arg, arg, yes of course. I actually did think about that, but still did not look carefully enough !! Really stupid of me. It is even worse because I wrote that code ... Now, the #printOn: of BenchmarkResult is much clearer, less confusing: ZnClient new in: [ :client | [ client get: 'http://localhost:8080' ] benchFor: 5 seconds ]. a BenchmarkResult(14,732 iterations in 5 seconds. 2,946 per second) vs ZnClient new in: [ :client | client loggingOff. [ client get: 'http://localhost:8080' ] benchFor: 5 seconds ]. a BenchmarkResult(42 iterations in 5 seconds 88 milliseconds. 8.255 per second) Still the same issue with $, and $. in frequency, but the iteration count is crystal clear. The reason #bench works like that is backwards compatibility at the time we introduced that. @ Ben Yes, I should have looked at the other side as well, to confirm things actually happened as I imagined them (the did not). Thx and sorry for the noise. Sven > On 10 Dec 2017, at 18:00, Henrik-Nergaard <draagren(a)outlook.com> wrote: > > Hi Sven, > > What you are seeing is most likely a $, vs $. issue. > See BenchmarkResult >>#printFrequenceOn: it uses both decimal and thousand > separators. > > If i run this code: > ----------------------------------------- > | counter | > counter := > ZnClient new in: [ :client | > client loggingOff. > [ client get: 'http://localhost:8080'. counter ] bench > ]. > counter. > ----------------------------------------- > > Then i get 9035 ('1,773 per second') when no inspector is open, and only 22 > ('5.995 per second') when inspecting the logs. > > Best regards, > Henrik > > > > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Dec. 10, 2017

Re: [Pharo-dev] Weird ZnClient benchmarking result

by Henrik Sperre Johansen

Sven Van Caekenberghe-2 wrote > Hi, > > While benchmarking ZnClient I encountered something weird and counter > intuitive that I cannot explain. > > This was on macOS running Pharo 7 and 6. > > First you need to setup a fast local HTTP server, can be anything, for > example: > > $ brew install nginx > $ brew services start nginx > $ curl http://localhost:8080 > > In Pharo, the benchmark code looks as follows: > > ZnClient new in: [ :client | > [ client get: 'http://localhost:8080' ] bench ]. > > On my machine this gives about 2500 req/s. > > ZnClient uses object logging: it emits special event objects that contain > information regarding what happens (full details and timing information) > using an Announcer. Subscribers can then decide what to do with this > detailed information. This mechanism is always active, but there is an > option to turn it totally off for maximum performance: > > ZnClient new in: [ :client | > client loggingOff. > [ client get: 'http://localhost:8080' ] bench ]. > > This gives about 3000 req/s, a non-trivial + 500 req/s improvement. > > Now comes the weird thing. GT contains a custom view for Announcers, > inspect: > > ZnLogEvent announcer. > > And select the Announcements tab. Leave this window open. > > Now, the first expression (with full logging enabled and an active > subscriber with a UI) is way FASTER than first, it yields about 7000 to > 8000 req/s. Since the benchmark runs in the main UI thread, no actual > drawing happens until the expression finishes. > > Running both expression inside a Time profiler show how in the first case > significant time (actually *most* time ;-) is spent in the logging: > > > > In the second case, with logging disabled, that changes to: > > > > One has to take into account that the request has to be processed by the > server, so from the client's perspective, most time will always be spent > waiting for a reply, #readResponse. With the logging enabled, probably > less time is spent waiting, since the client does a bit more work. Still > what should be slower is more than 2 times as fast ! > > I have a feeling that this has to do with scheduling (probably interacting > with network IO), as going deep into the last #readResponse above, I see: > > > > But I still cannot understand why doing apparently more work results in > faster throughput. > > Can anyone explain this behaviour ? > > Thx, > > Sven > > > > Screen Shot 2017-12-10 at 16.59.36.png (68K) > <http://forum.world.st/attachment/5060328/0/Screen%20Shot%202017-12-10%20at%2016.59.36.png> > Screen Shot 2017-12-10 at 17.00.28.png (60K) > <http://forum.world.st/attachment/5060328/1/Screen%20Shot%202017-12-10%20at%2017.00.28.png> > Screen Shot 2017-12-10 at 17.07.39.png (140K) > <http://forum.world.st/attachment/5060328/2/Screen%20Shot%202017-12-10%20at%2017.07.39.png> Just a theory, but iirc, if the vm heartbeat thread isn't running properly, newly arrived external events only gets checked every N executed bytecodes. Could explain an increase in delay times before the socket semaphore is signalled. Should be easily testable, any low-priority thread with an infinite loop would probably do enough work. Cheers, Henry -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Dec. 10, 2017

Re: [Pharo-dev] Weird ZnClient benchmarking result

by Henrik-Nergaard

Hi Sven, What you are seeing is most likely a $, vs $. issue. See BenchmarkResult >>#printFrequenceOn: it uses both decimal and thousand separators. If i run this code: ----------------------------------------- | counter | counter := ZnClient new in: [ :client | client loggingOff. [ client get: 'http://localhost:8080'. counter ] bench ]. counter. ----------------------------------------- Then i get 9035 ('1,773 per second') when no inspector is open, and only 22 ('5.995 per second') when inspecting the logs. Best regards, Henrik -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Dec. 10, 2017

Re: [Pharo-dev] Weird ZnClient benchmarking result

by Ben Coman

On 11 December 2017 at 00:14, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > While benchmarking ZnClient I encountered something weird and counter > intuitive that I cannot explain. > > This was on macOS running Pharo 7 and 6. > > First you need to setup a fast local HTTP server, can be anything, for > example: > > $ brew install nginx > $ brew services start nginx > $ curl http://localhost:8080 > > In Pharo, the benchmark code looks as follows: > > ZnClient new in: [ :client | > [ client get: 'http://localhost:8080' ] bench ]. > > On my machine this gives about 2500 req/s. > > ZnClient uses object logging: it emits special event objects that contain > information regarding what happens (full details and timing information) > using an Announcer. Subscribers can then decide what to do with this > detailed information. This mechanism is always active, but there is an > option to turn it totally off for maximum performance: > > ZnClient new in: [ :client | > client loggingOff. > [ client get: 'http://localhost:8080' ] bench ]. > > This gives about 3000 req/s, a non-trivial + 500 req/s improvement. > > Now comes the weird thing. GT contains a custom view for Announcers, > inspect: > > ZnLogEvent announcer. > > And select the Announcements tab. Leave this window open. > > Now, the first expression (with full logging enabled and an active > subscriber with a UI) is way FASTER than first, it yields about 7000 to > 8000 req/s. Since the benchmark runs in the main UI thread, no actual > drawing happens until the expression finishes. > Can you compare logging from Nginx to confirm the additional requests. Perhaps in the second case each Annoucement is being re-Announced. cheers -ben > > Running both expression inside a Time profiler show how in the first case > significant time (actually *most* time ;-) is spent in the logging: > > > In the second case, with logging disabled, that changes to: > > > One has to take into account that the request has to be processed by the > server, so from the client's perspective, most time will always be spent > waiting for a reply, #readResponse. With the logging enabled, probably less > time is spent waiting, since the client does a bit more work. Still what > should be slower is more than 2 times as fast ! > > I have a feeling that this has to do with scheduling (probably interacting > with network IO), as going deep into the last #readResponse above, I see: > > > But I still cannot understand why doing apparently more work results in > faster throughput. > > Can anyone explain this behaviour ? > > Thx, > > Sven > >

Dec. 10, 2017

Weird ZnClient benchmarking result

by Sven Van Caekenberghe

Hi, While benchmarking ZnClient I encountered something weird and counter intuitive that I cannot explain. This was on macOS running Pharo 7 and 6. First you need to setup a fast local HTTP server, can be anything, for example: $ brew install nginx $ brew services start nginx $ curl http://localhost:8080 In Pharo, the benchmark code looks as follows: ZnClient new in: [ :client | [ client get: 'http://localhost:8080' ] bench ]. On my machine this gives about 2500 req/s. ZnClient uses object logging: it emits special event objects that contain information regarding what happens (full details and timing information) using an Announcer. Subscribers can then decide what to do with this detailed information. This mechanism is always active, but there is an option to turn it totally off for maximum performance: ZnClient new in: [ :client | client loggingOff. [ client get: 'http://localhost:8080' ] bench ]. This gives about 3000 req/s, a non-trivial + 500 req/s improvement. Now comes the weird thing. GT contains a custom view for Announcers, inspect: ZnLogEvent announcer. And select the Announcements tab. Leave this window open. Now, the first expression (with full logging enabled and an active subscriber with a UI) is way FASTER than first, it yields about 7000 to 8000 req/s. Since the benchmark runs in the main UI thread, no actual drawing happens until the expression finishes. Running both expression inside a Time profiler show how in the first case significant time (actually *most* time ;-) is spent in the logging: In the second case, with logging disabled, that changes to: One has to take into account that the request has to be processed by the server, so from the client's perspective, most time will always be spent waiting for a reply, #readResponse. With the logging enabled, probably less time is spent waiting, since the client does a bit more work. Still what should be slower is more than 2 times as fast ! I have a feeling that this has to do with scheduling (probably interacting with network IO), as going deep into the last #readResponse above, I see: But I still cannot understand why doing apparently more work results in faster throughput. Can anyone explain this behaviour ? Thx, Sven

Dec. 10, 2017