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

Re: [Pharo-dev] Mocketry names again

by Denis Kudriashov

2016-04-20 20:36 GMT+02:00 S Krish <krishnamachari.sudhakar(a)gmail.com>: > result should return: [mock someMessage] It should verify that result was returned from message defined inside block. That's why I use "should beReturnedFrom: [mock someMessage]". Following test demonstrates idea: mock := Mock new. mock stub someMessage willReturn: #result. mock stub anotherMessage willReturn: #anotherResult. mock someMessage should be: #result. mock anotherMessage should be: #anotherResult. #result should beReturnedFrom: [mock someMessage]. #result should not beReturnedFrom: [mock anotherMessage]

April 20, 2016

Re: [Pharo-dev] What the state of unifying Beacon with SystemLogger?

by Ben Coman

Sorry for not having a better reviewed understanding of both frameworks, but I have some thoughts from perspective of one user... On Thu, Apr 21, 2016 at 12:05 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hi. > > Thank's for answers. > > 2016-04-20 10:53 GMT+02:00 Norbert Hartl <norbert(a)hartl.name>: >> >> Agreed. As I said above. If you take to point of view from legacy logging >> tool Beacon is not a big help. But the ideas in it are good and should be >> integrated somewhere. If you are talking about legacy tooling it might ok to >> use the terms logging as well, no? I personally like the work Beacon but in >> my opinion it is wrong for this purpose. A beacon sends a uniform signal in >> order to be discovered. The Beacon code sends signals to a beacon. And I can >> register at the beacon in which signals I'm interested in. Feels wrong to >> me. > > > Your words are reasonable. Interesting what Tudor think about it? > > There are few things which I not like in SystemLogger (which not means that > everything is good with Beacon): > > name Log to represent records of the underlying "physical log". > > IMHO Log means exactly end logging backend like text file, syslog or > external database. Log is the place where we can explore (read) what was > happen. You are considering Log as a noun, but it can also be used as a verb. defn "13. to enter in a log; keep a record of; e.g. to log a day's events." [1] Stef said: "Remember that you want to have them short especially for the main one. This is why in SystemLogger we have Log instead of what it is LogObject" from which I understood that Log was the client interface, to be used like Transcript. I think this is a good idea. It would create the LogEntry [1] http://www.dictionary.com/browse/log > And now these backends are represented by subclasses of Logger: > StdoutStreamLogger, SysLogSender. I would call them StdoutLog, SysLog. > But with such change we need to call log entry differently. It can be > LogRecord or LogEntry. I not understand what was the problem with such > names? (there was some explanation why Log was chosen for this) Considering a "log" being the final resting point of the logged objects, that is the external disk text file or database, then within Pharo we don't have logs, only processes that write to the external logs, so Logger seems appropriate. This is except for an in memory log, which for backend might need both MemoryLogger and MemoryObjectLog. Log would create and send theLogEntry to SystemLogger which forwards theLogEntry to other registered XXXLogger backend. > name SystemLogger for collection based log. > > SystemLogger makes me think that it is singleton which is used by system and > I should not use it for my own application. I guess your application would make use SystemLogger via Log at the front end, and registering backends with SystemLogger. > I would call it like ObjectLog or NativeLog (following my first sentence > about Log). NativeLog doesn't seems right. ObjectLog might be suitable for an in-memory backend, like above I mention MemoryObjectLog. > Also it is intercepted with SysLog name and I guess that's why it was called > SysLogSender and not SysLogLogger. > > name LogDispatcher. LogDispatcher is okay, but I'm not sure of convention to be associate the "doer" with the "target" rather than the "item", where doer=Dispatcher; item=LogEntry; target=final-backend-log; A little it sounds like its dispatching a whole log rather than one log entry. Maybe should be LogEntryDispatcher(??) or... SystemLogger as the marshalling point to forward to other XXXLoggers. > > Here same problem as Log. What means physical logs dispatching? I know it is > introduced around Log as log entry. But it is not intuitive for me (same as > Log). I don't think Log should be a log entry. It should be the user interface that creates and sends LogEntries via some XXXLogger. > In context of Log as real log (FileLog, SysLog) I would call this dispatcher > as Logger with same responsibility to register new events in all registered > logs. > > > announcements LogAdded and LogRemoved in the core. > > Why any Logger should announce every log entry? > I think we not need special LoggerUI app. We can just inspect SystemLogger > instance to look at all recorded objects. And in perspective of my > suggestions it will mean that we just explore particular ObjectLog. And we > can extend GTInspector for this. GTInspector would need good live updating, filtering, clearing, scrolling to keep cursor position as new entries arrive. cheers -ben

April 20, 2016

Re: [Pharo-dev] Mocketry names again

by S Krish

result should return: [mock someMessage] On Wed, Apr 20, 2016 at 1:35 PM, S Krish <krishnamachari.sudhakar(a)gmail.com> wrote: > +1. > > this is easy and simple for any native / non native english .. > > Mocketry is really nice btw.. > > On Wed, Apr 20, 2016 at 7:45 AM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> >> 2016-04-20 13:59 GMT+02:00 Dennis Schetinin <chaetal(a)gmail.com>: >> >>> Why do we need those sophisticated past-something form after should at >>> all? Why not simply >>> >>> mock should receive someMessage >>> >>> ? >>> >> >> Maybe. What others think? >> > >

April 20, 2016

Re: [Pharo-dev] Mocketry names again

by S Krish

+1. this is easy and simple for any native / non native english .. Mocketry is really nice btw.. On Wed, Apr 20, 2016 at 7:45 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2016-04-20 13:59 GMT+02:00 Dennis Schetinin <chaetal(a)gmail.com>: > >> Why do we need those sophisticated past-something form after should at >> all? Why not simply >> >> mock should receive someMessage >> >> ? >> > > Maybe. What others think? >

April 20, 2016

Re: [Pharo-dev] Class allSubInstances size takes 23 seconds to run on Pharo 5 on OS X

by Denis Kudriashov

2016-04-20 17:47 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Pavel, > > On Apr 20, 2016, at 6:54 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> > wrote: > > That is not real amount of objects in the object memory: > > count := 0. > object := 0 someObject. > [object == 0] whileFalse: [ > count := count + 1. > object := object nextObject ]. > count. "->724653" > > > Right. allObjects size is approximately equal to Object allSubInstances > (but much faster to evaluate, since it makes only a single heap > traversal). Class allSubInstances answers only classes, not those class's > instances. > But my test was not about Object allSubInstances but about Object allSubclasses. I supposed that "Class allSubInstances size" should equal "(Class *allSubclasses* flatCollect: [ :each | each allInstances ]) size". But it is not. And it is surprised me. Interesting to know why.

April 20, 2016

Re: [Pharo-dev] What the state of unifying Beacon with SystemLogger?

by Denis Kudriashov

Hi. Thank's for answers. 2016-04-20 10:53 GMT+02:00 Norbert Hartl <norbert(a)hartl.name>: > Agreed. As I said above. If you take to point of view from legacy logging > tool Beacon is not a big help. But the ideas in it are good and should be > integrated somewhere. If you are talking about legacy tooling it might ok > to use the terms logging as well, no? I personally like the work Beacon but > in my opinion it is wrong for this purpose. A beacon sends a uniform > signal in order to be discovered. The Beacon code sends signals to a > beacon. And I can register at the beacon in which signals I'm interested > in. Feels wrong to me. Your words are reasonable. Interesting what Tudor think about it? There are few things which I not like in SystemLogger (which not means that everything is good with Beacon): - name Log to represent records of the underlying "physical log". IMHO Log means exactly end logging backend like text file, syslog or external database. Log is the place where we can explore (read) what was happen. And now these backends are represented by subclasses of Logger: StdoutStreamLogger, SysLogSender. I would call them StdoutLog, SysLog. But with such change we need to call log entry differently. It can be LogRecord or LogEntry. I not understand what was the problem with such names? (there was some explanation why Log was chosen for this) - name SystemLogger for collection based log. SystemLogger makes me think that it is singleton which is used by system and I should not use it for my own application. I would call it like ObjectLog or NativeLog (following my first sentence about Log). Also it is intercepted with SysLog name and I guess that's why it was called SysLogSender and not SysLogLogger. - name LogDispatcher. Here same problem as Log. What means physical logs dispatching? I know it is introduced around Log as log entry. But it is not intuitive for me (same as Log). In context of Log as real log (FileLog, SysLog) I would call this dispatcher as Logger with same responsibility to register new events in all registered logs. - announcements LogAdded and LogRemoved in the core. Why any Logger should announce every log entry? I think we not need special LoggerUI app. We can just inspect SystemLogger instance to look at all recorded objects. And in perspective of my suggestions it will mean that we just explore particular ObjectLog. And we can extend GTInspector for this.

April 20, 2016

Re: [Pharo-dev] Class allSubInstances size takes 23 seconds to run on Pharo 5 on OS X

by Eliot Miranda

Hi Pavel, > On Apr 20, 2016, at 6:54 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > That is not real amount of objects in the object memory: > > count := 0. > object := 0 someObject. > [object == 0] whileFalse: [ > count := count + 1. > object := object nextObject ]. > count. "->724653" Right. allObjects size is approximately equal to Object allSubInstances (but much faster to evaluate, since it makes only a single heap traversal). Class allSubInstances answers only classes, not those class's instances. > > 2016-04-20 15:18 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >> And here other interesting results: >> >> Class allSubInstances size. >> "5636" >> Object allSubclasses size >> "11267" >> >> What they are not almost equal? >> >> 2016-04-20 14:54 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >>> Interesting. It takes very high amount of time on Pharo 2.0 too. >>> >>> -- Pavel >>> >>> 2016-04-20 14:26 GMT+02:00 Bernhard Pieber <bernhard(a)pieber.com>: >>>> Dear Pharoers, >>>> >>>> I found something strange: >>>> Time millisecondsToRun: [ Class allSubInstances size ]. â23617" >>>> >>>> I did this on a new Pharo 5 image >>>> curl get.pharo.org/alpha+vmLatest | bash >>>> >>>> Can somebody confirm this on their machine? What might be the reason? >>>> >>>> Cheers, >>>> Bernhard >

April 20, 2016

Re: [Pharo-dev] Class allSubInstances size takes 23 seconds to run on Pharo 5 on OS X

by Eliot Miranda

Hi Bernhard, > On Apr 20, 2016, at 5:26 AM, Bernhard Pieber <bernhard(a)pieber.com> wrote: > > Dear Pharoers, > > I found something strange: > Time millisecondsToRun: [ Class allSubInstances size ]. â23617" Because it does an allInstances for Class and all its subclasses, and allInstances visits every object in the heap, so this does thousands of scans of the heap. > I did this on a new Pharo 5 image > curl get.pharo.org/alpha+vmLatest | bash > > Can somebody confirm this on their machine? What might be the reason? > > Cheers, > Bernhard

April 20, 2016

Re: [Pharo-dev] Class allSubInstances size takes 23 seconds to run on Pharo 5 on OS X

by Ben Coman

On Wed, Apr 20, 2016 at 9:18 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > And here other interesting results: > > Class allSubInstances size. > "5636" * 2 = 11272 > Object allSubclasses size > "11267" > > What they are not almost equal? Strange that its out by a factor of two. Its almost like each class is also an object ;) cheers -ben > > 2016-04-20 14:54 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >> >> Interesting. It takes very high amount of time on Pharo 2.0 too. >> >> -- Pavel >> >> 2016-04-20 14:26 GMT+02:00 Bernhard Pieber <bernhard(a)pieber.com>: >>> >>> Dear Pharoers, >>> >>> I found something strange: >>> Time millisecondsToRun: [ Class allSubInstances size ]. â23617" >>> >>> I did this on a new Pharo 5 image >>> curl get.pharo.org/alpha+vmLatest | bash >>> >>> Can somebody confirm this on their machine? What might be the reason? >>> >>> Cheers, >>> Bernhard >> >> >

April 20, 2016

[Pillar]Â Pillar 3.0.0 release

by Thibault ARLOING

Hi everybody, I'm happy to announce the latest release of Pillar. This release has been possible because of the hard work of Damien Cassou, Cyril Ferlicot, Damien Pollet, Stephan Eggermont, Yann Dubois, Thibault Arloing and Lukas Komarek. What did it bring and what are the largest changes ? * Addition of an AsciiDoc Exporter * LaTeX exporter: * external links now produce footnotes * replace \begin{code}{} with \begin{listing}[language=XXXX] * replace \ct with \code * use \textasciitilde instead of \texttildelow to represent a ~ character in Pillar * SBALaTeX writer for sba book (by Damien Pollet) https://github.com/cdlm/sbabook * HTML exporter: * default template charset is UTF-8 * Features: For more you can see Pillar documentation at https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessf… * hideable scripts with the option hideable. * e.g., [[[hideable=true with a parameter in pillar.conf "scriptHide"=true this text will be hidden. ]]] * It's, for example useful if you're a teacher and you want to have two versions of your document, one with solutions (for you) and one without (for students) * auto anchor for headers * e.g, in a level configuration "level1":{ "numbering"=true, "autoAnchor"=true } there will be an automatic creation of an anchor for headers of level 1. * It's useful when you want to link a title in the text, for example for a table of contents * header capitalization in a level configuration with options: capitalize, capitalizeEnglish, uppercase, lowercase * ex: "level1":{ "capitalization":"uppercase" } Will render all headers of level 1 to Uppercase. * It's useful if you want all headers of a same level to be capitalize likewise * e.g., if you have "==i am a level 1 header" with "capitalizeEnglish" it will produce "<h2>I Am a Level 1 Header<\h2>" Cheers, Thibault

April 20, 2016