- Pharo-users - lists.pharo.org

Re: [Pharo-users] Pharo 7 image, some more size reducation

by Hilaire

Le 28/04/2018 Ã 12:11, phil(a)highoctane.be a Ã©critÂ : > > Very interesting to read that code. (There is a typo in workstation at > one point). Thanks, fixed. > > > > [2] > https://www.dropbox.com/s/a4wb7c6od4fdl9k/DrGeo.app-18.06a.zip?dl=0 > <https://www.dropbox.com/s/a4wb7c6od4fdl9k/DrGeo.app-18.06a.zip?dl=0> > > > Trying it out :-) Cool -- Dr. Geo http://drgeo.eu

April 29, 2018

Re: [Pharo-users] Showcasing Pharo, Roassal and Grafoscopio at re:publica 2018

by Offray Vladimir Luna CÃ¡rdenas

Thanks folks for all your support words and offerings. I am now still installing myself in Berlin, but as soon as I can, I will answer in a more detailed fashion. Cheers, Offray On 26/04/18 08:57, Offray Vladimir Luna CÃ¡rdenas wrote: > Hi, > > I will be showcasing Pharo, Roassal and Grafoscopio at re:publica 2018, > next week. As you may know, re:publica[2] is one of the most important > and visible media & digital culture conventions in Europe and is a good > scenario for the Pharo community.Â You can find details about my > participation at [1] > > [1] > https://18.re-publica.com/en/session/data-clinic-twitter-data-selfies-data-… > [2] https://18.re-publica.com/en > > I will be making intensive refactoring on the Dataviz package to create > some usual and unusual data visualizations from data exported from > Twitter, so I may be more active those days in the Discord and mailing > list channels, is some questions arise. > > Thanks in advance for the Pharo communities support. I wouldn't be able > to be there without it. > > Cheers, > > Offray > > > >

April 29, 2018

Re: [Pharo-users] Literals (Richard Sargent)

by Debiller 777

Well, set idea was just a small proposal, which had to help me in solving a harder problem. I wanted to add something like extensionable literal. The idea is that when compiler sees some special literal, it reads it, turns into an object and sends #parse message to it. After that literal answers something which compiler uses and considers as a result of this literal. Example: `#{1 2 3}` So compiler sees that literal initializes with it and object. Then object receives #parse message. It easily defines that its contents is set ctration and after parsing returns set object. This idea is my original intention. I hope its better than previous.

April 29, 2018

Smalltalk-76 Demo

by Bernardo Ezequiel Contreras

https://youtu.be/NqKyHEJe9_w -- Bernardo E.C. Sent from a cheap desktop computer in South America.

April 29, 2018

Re: [Pharo-users] Literals

by Sean P. DeNigris

Denis Kudriashov wrote > We have similar mechanizm in Pharo. Look at > http://dionisiydk.blogspot.fr/2016/07/magic-with-pharo-reflectivity.html Wow! That's really cool. I like that we can do it without adding *any* syntax. Tiny syntax is one of the more special things about the Smalltalk language. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

April 29, 2018

Re: [Pharo-users] Literals

by Richard Sargent

Debiller 777 wrote > You know, literals are quite useful in case when you want to shorten some > object initialization. For example #() and {} for arrays and $[]for byte > arrays. However, if there is a way to add custom literals, for example for > sets (something like #{} I guess)? how to do it? and can some special kind > of objects for creating literals easily be added to Pharo? The discussion on this topic has been quite interesting. However, I want to circle back to this original question; I think we've wandered from it in some respects. The original motivation was "when you want to shorten some object initialization". Typically, this kind of driver is a performance issue. As in, "I want to be able to initialize my instances with minimal overhead" so that e.g. the cost of creating instances is minimized and I can create and discard instances easily and frequently. I'm not saying that is the only motivation, but it is largely what I will address here. A number of messages discussed somewhat more elaborate syntax for literals, such as the example for a date #{'2018-05-01') or something close to that. And someone else will surely want #{'14:30'} for much the same justification. And yet others will want something else altogether. My of my all-time favourite design rules was something I read in 1989, loosely called the 0, 1, infinity rule. As soon as we go beyond one of something, there are an arbitrary number of possibilities we must deal with. That's not a burden we want to put on the compiler (or more likely on the parser). We could imagine that the syntax is a little more elaborate, such as #{Date '2018-05-01'} in which case the parser could automatically send the #fromString: message to the receiver Date using the argument of the string. Such an approach would give a general solution to a simple subset of the possible initializers one might encounter. However, it wouldn't handle other kinds of initialization, such as the Dictionary example I mentioned in my earlier response. It also wouldn't handle the issue of the implementation of #fromString: being changed and failing to recompile the literal that was generated independently of it. For the sake of argument, I think we can reasonably assert that #fromString: would be assumed to be correct and any changes in its implementation would not impact the literal that was previously and correctly created from that literal string. So, we have a proposal that with a small increase in the syntactic burden of the language does address a reasonable subset of the originally stated problem. But, it doesn't solve the general problem. For that reason alone, I don't agree with increasing the syntax of the language for it. Another respondent mentioned pool variables. These have the benefit that the name can be entirely informative and their values can be recomputed any time one wishes. In fact, they may already be the correct and complete answer. They aren't without their own costs, of course. Obviously, they must be defined before they can be referenced in the code that uses them. This pretty much requires a multiple package approach, requiring one package to define the pool variables (perhaps with only a place-holder value) and another package with the code that needs them. (VA Smalltalk has a technique that allows them to be defined in the same package, but at a terrible price: their definitions are opaque to the standard Smalltalk tools. We can discuss this on a separate thread if anyone wants to know more about that.) There is also the "once" block that I mentioned elsewhere. It typically uses a dictionary to cache the result of the first evaluation and then provide the look up on subsequent evaluations. One could also add a cached result instance variable to Block and avoid such a look up. It's still not as fast as a pool variable, of course. As a side note, I would like to remind everyone about Kent Beck's comments on literals. I'm paraphrasing him, but essentially there are only a very few literals which should be allowed to run around naked. The may be 0, 1, '', and possibly -1. Certainly every other literal should be encapsulated in an intention revealing name. Does May 1st mean something? If one is going to use it as I did in the examples above, it had better be given a name that everyone will be able to understand. For example, any reader would understand Float pi and the distinction between it and Double pi. A string of random digits takes considerably more parsing on the part of the reader to understand its intent. Lastly, I would encourage the original poster to elaborate on what problem or problems he is really trying to solve. (Over the years, I ave encountered many users who request a feature to solve a problem that isn't the real problem they need to solve. Programmers, too, make the same mistake.) -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

April 28, 2018

Re: [Pharo-users] Literals

by Denis Kudriashov

Hi. ÑÐ±, 28 Ð°Ð¿Ñ. 2018 Ð³., 1:26 Richard Sargent < richard.sargent(a)gemtalksystems.com>: > On Fri, Apr 27, 2018 at 3:58 PM, Esteban A. Maringolo < > emaringolo(a)gmail.com> wrote: > >> oh, you were talking about how te VM views the object, >> I was thinking in terms of how the compiler sees the text. >> >> So I'm talking about literals "syntax". >> >> Thanks anyway for the "trick" :) >> > > Another common technique is a "once block". Teach Block how to evaluate > itself once and to use its cached result the next time. > We have similar mechanizm in Pharo. Look at http://dionisiydk.blogspot.fr/2016/07/magic-with-pharo-reflectivity.html > It's not as fast as a literal, but it is a pretty effective way to have a > clean implementation with as complex code as one could wish. > Clear the cache when saving the image or at image start up or ... whenever > seems good (such as when you change the implementation of what was cached. > > e.g. > [Dictionary new > at: #a put: self something; > at: #b put: self somethingElse; > yourself] > once > > > >> >> On 27/04/2018 16:34, ClÃ©ment Bera wrote: >> > The guy who asked the question said: "...when you want to shorten some >> > object initialization" >> > >> > Using ClassVariable is an alternative way to shorten object >> > initialization, reading a ClassVariable is almost the same performance >> > as reading a literal, so that looked like a good alternative to me. Both >> > the ClassVariable and the literal have the same issues (same object so >> > if you mutate it you have to deal with it). >> > >> > But yes, it's not a new literal. >> > >> > For new literals, you can extend the compiler or hard patch thing: >> > >> > MyClass>>foo >> > ^ #bar >> > >> > (MyClass>>#foo) literalAt: ((MyClass>>#foo) literals indexOf: #bar) put: >> > Set new. >> > >> > MyClass new foo >> > >> >>>> a Set () >> > >> > Obviously it depends what you mean by literal, the latter code uses the >> > literal bytecode instruction, which does not make the pushed object a >> > literal object... >> >> >> -- >> Esteban A. Maringolo >> >> >

April 28, 2018

Re: [Pharo-users] Literals (Richard O'Keefe)

by Debiller 777

Can you please tell more about ##() thing?

April 28, 2018

[Ann] Iceberg 0.7.4

by Guillermo Polito

Hi all, Time for the weekly Iceberg update. The next pharo build will include Iceberg 0.7.4, with many improvements done during this last week. Documentation wise, all documentation/workflow valid for 0.7.3 is still valid for 0.7.4. Thanks to all brave users, issue reporters and contributors :). Key changes: - Several improvements in merging (mostly UI) - Optimize Pharo workflow (less fetches and unnecessary diffs) - Lots of new automated tests to cover merging, reverting and some git interactions that are difficult to capture manually Infrastructure changes: - Since 0.7.2 was released, we made the resolution of making an enhancement in the infrastructure per release - In 0.7.3 we fixed travis CI so builds are run on every commit and on pull requests - In this relese (0.7.4) we introduced in the build tests againt pharo 6.1 and 64 bits * The idea is to prepare the field for a future backport to Pharo 6.1 * And have good 64 bit support * https://travis-ci.org/pharo-vcs/iceberg/builds/372408795 In the next version our idea is to put the focus on enhancing - metacello integration - Pharo6.1 compatibility working smoothly - add a couple of more videos on scenarios like: * how to upgrade and contribute to iceberg * how to review a pharo fix * how to reuse your image for other fixes * handling merges * how to update a fork Here is the detailed changelog with all closed issues during this week: #729 Update .travis.yml to test Pharo 6 and 64 bits #689 Creating a repository in an existing location shows a debugger UI enhancement #556 Removed packages are not removed from git Model bug #727 Adapt properties reading of Tonel projects for Pharo 6.1. #728 Ask confirmation on fetch all action #543 In merge window removed methods are not taken into account Model bug #695 Specifying that Clone GitHub repository only deals with ssh mode Github plugin UI #690 Revert all does not behave correctly in detached working copy Model bug important #720 Commit panel should be selected by default when opening the commit window UI enhancement #724 Change focus order of commit window UI enhancement #719 Typing just after entering commit windows throw an error UI bug #721 Repository creation error not handled Github plugin bug #722 Typo in email git properties Libgit bug #716 "#pathString was sent to nil" if Pharo repository is not resolved Metacello Integration bug important #709 Cannot see the arrow in merge view #701 Merge view shows extra things UI enhancement merge #710 Merge does not apply changes right bug merge #711 The merge lose some changes bug merge #694 Extra diffs happen Model enhancement important #705 Clone repair action does extra actions Model enhancement #647 Following script for Pharo6.1 leads to unusable Iceberg (>>#binaryWriteStream) Pharo6-backport bug important Enjoy, Guille

April 28, 2018

Re: [Pharo-users] Literals

by Richard O'Keefe

A On 28 April 2018 at 20:21, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > What would entail actually extending the syntax and adding the set literal? > > From my brief observations (when I was discussing this with OP on discord): > > * adding a new AST node > * extend RBParser > * extend IRMethod/IRTranslator... maybe generating bytecode for `{ ... } > asSet` instead would be enough? (not sure how debugger would react to this) > > anything else? Would VM changes be required? > > I added > â '{' binarySelector expr '.' ... '.' expr ['.'] '}' to my âcompiler because I was sick of other people being able to write stuff more elegantly in Python than I could in Smalltalk. Here the binarySelector controls what kind of set: = Set == IdentitySet ?= CaseInsensitiveSet < SortedSet (splay trees) > SortedSet (with comparison reversed) <> TernarySet (ternary search string for strings). I'm not happy with the syntax, but it's the least ugly I've been able to find. Having syntax only for Set would be so limiting there'd be no real point. So. No change to the scanner. No change to the abstract syntax trees. {== x. y} generates the same syntax tree that ((IdentitySet new: 2) add: x; add: y; yourself) would have done. And therefore no change to the back end code generator. The *only* change was the parsing routine that responds to '{'. The fundamental issue is WHY you want an extension to the syntax. In my case, the {binarySelector exprs} syntax for sets and corresponding #{binarySelector maplets} syntax for dictionaries were to let me approximate the brevity of Python and Javascript. I didn't need new *semantics*. In contrast, the ##(expr) syntax in Dolphin, Smalltalk/X, and whatever others does NOT offer brevity at all but DOES offer new semantics. To the limited, not to say derisory, extent to which I understand the Dolphin compiler, it does have a special StOptimizedNode type of AST node for ##(...) forms. I don't *think* any VM changes are needed, unless of course you want to be able to decompile the byte-code and recover the ##(expr) source. I don't have a Windows box any more, so I can't run Dolphin, sorry, just admire it. I can say that it takes care not to put literals inside a ##(expr) form in the literal table.

April 28, 2018