August 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Dark Mode

by Dimitris Chloupis

> Kilon has blue-ish theme (I don't think he published it anywhere), > The theme is called Nireas , its a dark theme based on blue color and is inspired by the best computer of all time. Amiga 500. Nireas is also a special theme because its a themable theme. It comes with a GUI that allows you to change its colors very easily to whatever you like. Should have probably named it "Chameleon" ;) I was planning to create also a preset system for it but I have been so happy with the blue theme that I never bothered it , together with the fact that none shown an actual interest in having a theme creation GUI. Of course people think its a cool idea, but I am talking here actual help, not words. Its super easy to get Nireas, it installs with a single click from the Package Browser from inside the image , like you install many other things. Its tested with each version because well, I always use the latest version of Pharo and there is close to zero reason why it would not work other than someone actually changing the theme classes. Of course its hosted on Github https://github.com/kilon/Nireas

Aug. 27, 2017

Re: [Pharo-users] Dark Mode

by Dimitris Chloupis

> > > I completely agree - dark mode is great for content that you want to > look cool, but no one consumes. :-) > You assume wrong cause dark themes have been dominating GUIs for over 3 decades now. Pharo was the rare exception of using a white theme. Light themes may be popular but white are definitely not. The web is the last fort of bright themes, but the web was and still is eons behind when it comes to matters of UI. My first computer was black background with green fonts, black back in 80 and 90s was pretty much the norm. There was no white or bright themes back then. It was not because the monitors had any issues with displaying white. It was actually the web that made white a thing. Probably inexperienced web coders (there were no web devs back then ) thought it made sense transitioning from paper. Problem is that paper , reflects light, does not emit it. White or dark is a matter of preference. But the matter of preference is also a matter of biology . Not all eyes are same. Some eyes have hard time distinguishing elements in dark environments , others have hard time distinguishing elements in bright environments but excel at dark environments. I belong to the second case as such white themes for me are pretty much unacceptable for any content I have to read for a long time. My monitor as we speak is set to 1/16th of its brightness which is the minimum setting. During the day that sun goes in my room it goes up to 3/16 maximum. Above that I am forced to simply reduce the light in the room. Trying to use Moose especially that was even brighter it was even harder for me to the point I gave up and never used it since then. So yes there are many of us who were raised with dark themes, still use dark themes , will continue to use dark themes and criticise any app that does not support them. For me the Dark theme has been the most important improvement of Pharo and I am not exaggerating one tiny bit.

Aug. 27, 2017

Re: [Pharo-users] pillar image in external link (or html a tag)

by Peter UhnÃ¡k

I did a pass on the Markdown exporter to align it with CommonMark specifications, so it is exporter properly if I instantiate the objects. But Pillar also needs to parse the string properly. On Sun, Aug 27, 2017 at 8:28 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi peter > > I do not think you can. I learned this features friday while writing > md text to point to travis. > This is something that we will able to add but for now my focus is not > there. > Stef > > On Sat, Aug 26, 2017 at 10:41 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Hi, > > > > how can I embed an image into an anchor in Pillar? > > > > I've tried > > > > *+Pharo>https://pharo.org/web/files/pharo.png+>http://pharo.org/* > > > > I've also tried to create document by hand and export it, but every > single > > exporter failed on it. > > > > doc := PRDocument new > > add: (PRExternalLink new > > reference: 'http://pharo.org/'; > > add: (PRFigure new > > reference: 'https://pharo.org/web/files/pharo.png'; > > add: (PRText content: 'Pharo'); > > yourself > > ); > > yourself > > ); > > yourself > > > > Thanks, > > Peter > >

Aug. 27, 2017

Re: [Pharo-users] Parser failure on FFI pragmas declaration in Pharo 5

by Stephane Ducasse

> About deprecation, I found it fast because I think FFI as a key component of > a language. I imagine similar problems could happen when going from Morphic > to its successor (Bloc?). Even with a stable API, I expect some code to > explicitely depends on Morphic and break in the next GUI framework. I do not > think this can be avoided. I am aware that maintenance is very costly and > that it is always hard to be sure new users do not get caught in this kind > of change. (As far as I understand the old MVC framework was kept quite long > along with the at-the-time new Morphic to ensure smooth transition.) For Morphic I think that we will see but Bloc should not be killed on the altar of Morphic compatibility. We do not have much to keep from Morphic. > > Note that I am not trying to claim that Pharo generally is bad or worse than > another language. As a new user, my expectations were quite high after > spending a few weeks learning the language, going through the MOOC, being > able to tinker with the UI (looking at everything, modifying the World Menu, > etc.), looking into the details of the bytecode and the VM. All of these > worked very well and I still do think that Pharo is a great of software as I > wrote in a previous question. Even when facing the UI problem in Pharo 5 due > to old FFI syntax, I was able to hack into the code and get it work. In > another language hitting an "internal" problem often is a dead end. > > I cannot tackle the problems I highlighted by myself. But with the help of > someone who knows how to address them in the Pharo's way, I am willing to > help. Esteban told me that it was decided that the parser was not maintain for the ffi. Now what would be great is to port the library to Pharo and newFFI. > About dependencies and version, I knew of Metacello configurations when I > wrote my first message and I was thinking of Pharo version (more precisely > the versions of core packages and dependencies as opposed to other external > packages that should be loaded on top of a freshly downloaded image). > I did not know that Pharo version was in configurations. So I had a look at > ConfigurationOfZeroMQ and maybe it keeps on being an exception but I did not > find any dependency on Pharo version in it. it is normal because we do not have yet metadata for loaded packages However it declares a dependency > on FFI version 1.4, which eventually is better than explicitely setting a > dependency on a Pharo version. I also had a look at the "validate" class > method and its comment that mentions "MetacelloMCVersionValidator". How is > this validation mechanism triggered? I could work on it and modify the > source code loader(s) so that instead of getting a syntax error in Pharo 6 I > get an error or a critical warning from the validator. (I loaded the package > by adding the corresponding repository in the Monticello browser and loading > ZeroMQ and ConfigurationOfZeroMQ last versions.) > > I eventually found what you talked about. In ConfigurationOfFFI, "stable:" > method lists the FFI versions that Pharo versions supports. The convention > for versioning is not clear to me: old FFI is supposed to work up to Pharo 4 > and the spec says FFI should be 1.7 to 1.9, which would mean that if a > package needs version x, any version y>=x is ok, but from Pharo 5 (which > requires FFI 1.10.1) it should fail, which would mean that version x should > be matched exactly (or an interval should be defined). > In Pharo 6 ConfigurationOfUnifiedFFI>>version_0_26_8 declares a dependency > on FFI-Kernel âFFI-Kernel-EstebanLorenzano.45â, which I do not understand. > Maybe here I can remove FFI dependencies. (Is this what you meant when > saying you could have deprecated it but did not do it?) > Besides ConfigurationOfFFI is not included in a freshly downloaded Pharo > image (I checked for Pharo 5), I found a reference to it in > ConfigurationOfUnifiedFFI (in the "ffi:" method) and manually added the > corresponding repository (MetaRepoForPharo50) in Monticello browser and > loaded the last version of ConfigurationOfFFI. So it seems that the info is > not available by default. That I do not know :) > I had also a look at FFI-Kernel package (the object as found by running > "RPackageOrganizer default packages select: [:p | p name = #'FFI-Kernelâ].") > and could not find any version info. Is it correct that the version info of > a package is only available through ConfigurationOf... and is not included > in the package object? > > If I understand well, a way to correct the problem would be: > - to ensure (or set it as an option for a start) that Metacello validation > is triggered even when loading source code and let the user choose from an > option whether it wants errors at loading stage or only warnings (and expect > problems when running). > - add all the ConfigurationOf that are in "Pharo/MetaRepoForPharo50/main" > repository in the corresponding official image (maybe rather do this for > Pharo60 which is still maintained) so that the validation gets all the > needed info > - as you mentioned in an earlier message ConfigurationOf for some "internal" > packages (included in a freshly downloaded Pharo image) are missing, so add > them, attribute them a version and set dependencies accordingly. (I can > help, it is a good way to learn about the internals of the language.) > Is it correct? (I can also work on the validator with some help.) I do not know . What I would do for now is - port the library to latest Pharo stable - make sure that you are succesful with your project - Of course you can help by fixing some aspects of Pharo you want to see improved :) I hope that we will deliver package metadata and the tooling. > > About correcting the specific problem I had in Pharo 5. Esteban told me that > it was not useful so I am confused now. > > About 0mq, I am not an expert of the (original) C library and of the python > bindings. The library sets up sockets for communication between processes > and even if you can serialize them apparently ZeroMQ is relatively brittle > as regards initialization (and this is one of its flaws). The author of the > ZeroMQ Pharo package was aware of the persistence problem and mentioned he > could not solve it completely. This is not an easy problem apparently. > About python bindings, they abstract initialization a bit and more > importantly offer abstractions to process the messages through the sockets: > integration with the async python 3 framework and with a popular event loop > (python tornado library from Facebook) are offered. It is much easier to > work with ZeroMQ this way as you do not have to care about low-level IO > details. (I do not know how it is done in the python bindings but for > example to listen to the socket either an event loop could take care of the > regular polling of the sockets or one could set up a thread that listens to > the socket through a blocking call.) Thanks for the description. > The equivalent in Pharo might be to integrate ZeroMQ with the GUI event > loop. (Not something I am able to do unfortunately.) > > Thanks, > Bruno > > > > -- > View this message in context: http://forum.world.st/Parser-failure-on-FFI-pragmas-declaration-in-Pharo-5-… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

Aug. 27, 2017

Re: [Pharo-users] pillar image in external link (or html a tag)

by Stephane Ducasse

Hi peter I do not think you can. I learned this features friday while writing md text to point to travis. This is something that we will able to add but for now my focus is not there. Stef On Sat, Aug 26, 2017 at 10:41 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Hi, > > how can I embed an image into an anchor in Pillar? > > I've tried > > *+Pharo>https://pharo.org/web/files/pharo.png+>http://pharo.org/* > > I've also tried to create document by hand and export it, but every single > exporter failed on it. > > doc := PRDocument new > add: (PRExternalLink new > reference: 'http://pharo.org/'; > add: (PRFigure new > reference: 'https://pharo.org/web/files/pharo.png'; > add: (PRText content: 'Pharo'); > yourself > ); > yourself > ); > yourself > > Thanks, > Peter

Aug. 27, 2017

Re: [Pharo-users] Copy bitmap to clipboard

by Stephane Ducasse

Hilaire may be you should turn the copied canvas into a png because it is not clear how external tools will be able to do something with an internal representation of the screen. Stef On Sun, Aug 27, 2017 at 6:18 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > I don't know about other platforms, but on linux the clipboard is > implemented in this 8kloc C file > https://github.com/pharo-project/pharo-vm/blob/e0ce2d9d78c3c7b37bbc12cd8730… > > e.g. getting the selection > https://github.com/pharo-project/pharo-vm/blob/d06aa80a38bc1b6d1f4cc54301ec… > > From the comments around the code I gather that the author(s) were aware > that images can be copied around in clipboard. Whether it actually works I > do no know. > > (it would be if the clipboard-related code wrote itself into a nice separate > file/plugin :)) > > Peter > > > > On Thu, Jun 15, 2017 at 4:00 PM, Hilaire <hilaire(a)drgeo.eu> wrote: >> >> Hi, >> >> A Dr. Geo user asked me about copying a DrGeo canvas view in the system >> clipboard, to past it in other tools as a text writer or any other >> editing tool. >> >> I looked in Pharo3 and Pharo6, I found text clipboard operation but it >> is not clear if there is support for other format? >> >> What about >> primAddClipboardData:data:dataFormat: >> >> I would like to copy and paste the DrGeo canvas as PNG content. >> >> -- >> Dr. Geo >> http://drgeo.eu >> >> >

Aug. 27, 2017

Re: [Pharo-users] [ann] moldable editor - with expandable elements

by Thierry Goubier

Hi Doru, thanks for the explanation... I'll end up with three questions: - What makes Bloc different compared to the InterViews and Amulet toolkits? And Unidraw? - Will some of your workflows enables exploration of parallel, non-deterministic programs? - Will we be able to have non-linear execution paths and explorations through examples and documentation? Regards, Thierry 2017-08-27 13:37 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi Thierry, > > Indeed, you noticed correctly that we stayed away from the code browser. > > We found several years ago that Morphic was too limiting. During the > Spotter implementation we found ourselves having to construct a > mini-Morphic in order to do what we wanted to do. With text we had several > prototypes for a different kind of editing experience, but we hit a wall. > The interface from the GTInspector is the most rudimentary solution we > could put in place, and it is there mostly as a placeholder to get over the > bridge. > > This is why we joined the Bloc project and we focused all our tool > development effort on it. The goal is to be able to build interfaces that > do not yet exist and that enable workflows that are radically different. We > showed can do that once we have an infrastructure, and we will continue to > do it until we have a full development experience. > > We did not start from the experience of writing code explicitly. That is > because the IDE should encompass all activities including the way we > understand a system, and we think that focusing on reading is to be left > for the previous century. So, we started from the inspector and debugger > and we are making our way towards the writing part. > > Writing code is certainly of deep interest to us. However, the system > browser is the least interesting of the places where we want to write code. > That is because we want to code against live objects, not against dead > text. The main use case the system browser is good for is to organize code > and to find a starting place for getting to a living object. For the rest > of the use cases, there are other solutions that are better. For example, > even with the current Playground, we have people spending more time in > there than in the code browser. That says something given that the > Playground is quite bare at the moment. > > We do not think in terms of tools, but the overall workflows we want to > support. Itâs not a race against features, but a reimagining of what an > experience can be like. For example, letâs take documentation: right now, > both producing and consuming documentation happens mostly outside of the > environment. So, the I in the IDE is failing in this respect. We want to > make both of these activities more attractive inside the environment and > the demo you see here is a step in that direction. There is no name for > this tool yet because we tend to not phrase the problem like that. > > Related to other editors, there are indeed WYSWIG tools, but they are > typically not dynamic. There are viewers that are dynamic, but they tend to > not scale well and not be editable. There are tools that scale, but they > are not too visual. And even when there exist some, they are not in an IDE. > So, yes, there are pieces that already exist, but the way we apply them is > novel. > > As for syntax highlighting, it is tied to text and attributes but only to > the extent we wanted it to be. The current implementation is 2k lines of > code. In comparison, just the core of Rubric is 5.5k. But, the rendering is > not related to text whatsoever. Word and adornments are just element that > conform to a layout. So, this means that people can build something else at > a much smaller costs should they want to. > > Cheers, > Doru > > > > On Aug 27, 2017, at 10:43 AM, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > > > Hi Doru, > > > > 2017-08-27 9:24 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > > Hi, > > > > > On Aug 27, 2017, at 12:06 AM, Thierry Goubier < > thierry.goubier(a)gmail.com> wrote: > > > > > > Hi Tim, > > > > > > 2017-08-26 23:27 GMT+02:00 Tim Mackinnon <tim(a)testit.works>: > > > I think you pose some interesting design challenges - but it's worthy > of experimentation. > > > > > > I share Denis' enthusiasm to build something better - but it's true > it's not an easy problem space. > > > > > > I'm a big fan of GTInspector, but sometimes I slide across and lose my > context (not always, and not for all types of problems). > > > > > > I think you may be on the key issue, the loss of context when > navigating through the code. In the 90's, that was called the 'lost in > hyperspace' problem linked with hypertexts and hypermedia. > > > > > > I'm not sure it was ever resolved (I stopped following that research > community during my PhD), apart from considering that google solved it for > the web. At least, this would be the choice made by Newspeak: consider that > the code is like the web, and build a system web browser. > > > > > > > > > For unique extractions - inlining is a no brainer (it's just like code > folding in many editors). For non-unique, maybe something in the gutter > might let you easily flip... I don't know, but I'm not convinced our > current way is always optimal. > > > > > > Agreed. I have changed the way I code to reduce the context needed to > understand it. > > > > > > > > > Still, the whole moldable idea is to make it easy to experiment - and > that's the cool bit. That's where we thrive. > > > > > > Smalltalk has allways been open to that sort of experiment. The > moldable bit may make it easier, or at least not more complex than it was > when Smalltalk systems were a lot smaller. Now, is that moldable > implementation really that free, or has it sacrificed certain freedoms to > make moldable things easier? > > > > Please let me intervene briefly :). > > > > Smalltalk was always indeed open. However, we noticed that regardless of > the application domain, tools essentially looked the same for these > systems. All Smalltalkers I asked extended Object at least once, but before > the GTInspector, most of them never extended the inspector. Our language > was extremely dynamic, but our tools less so. That is a conceptual problem > that we address with what we call moldability. > > > > Hum. From 1992 to now, I would make the same statement in the Smalltalk > world, mostly talking a certain conservatism first (look at how much the > system browser has evolved over the years), but also some questions about > efficiency of alternative forms. > > > > For example, the code view of the GTInspector remain for me as one of > the clumsiest, worse view I've ever seen in the Smalltalk world for editing > code. > > > > > > The goal of moldability is to make it inexpensive to customize. To this > end, we approach the IDE as a language and the moldability is captured in > the operators that language provides. Of course, there are limitations to > what can be doable inexpensively. However, it turns out that if you do > manage to bring the cost to a radical low cost, you get much more > extensions and experimentations going on. > > > > I'm a bit missing where the moldability of the IDE went, in that > context. You seem to stear very clear from anything related to the system > browser... > > > > > > All infrastructures make certain things easier and others less so. The > value of all this does depend on what are the operators and how deep in the > infrastructure they are placed. For example, the moldable editor shows > these expandable elements as part of syntax highlighting. Syntax > highlighting existed since a long time, so making it also able to show > other things is quite powerful and requires nothing hardcoded. In fact, I > do not know of any other editor that can do that while still having the > performance we get. > > > > ? Especially that last statement. > > > > Adding non text elements in an editor has allways been a fairly easy > endeavour in ST, as long as I could remember (1993?). > > > > Performance on long texts is orthogonal to Bloc, right? It is present in > all editors that do formatting on long documents since the first WYSIWIG > editors appeared in the 80's. > > > > And, so far, the examples you're showing means that editor isn't as > capable as Doc (in 1989/1990?) was. > > > > I a bit worried about that syntax highlighting approach. It seems to me > very tied to a text + attributes representation instead of an object > representation, and I find that API in Pharo horribly clumsy and > ineffective, for the apparent benefit of slightly reducing object storage > size with a kind of RLE compression. > > > > > > But, even more important than tool features is the behavior of people. > For example, when we first introduced the inspector, all talk was about > details (e.g., how it is clumsy to navigate laterally). 2 years later, at > this yearâs PharoDays most talks used the GTInspector in one way or another > to exemplify the presentation. This is a significant impact and this is > what we are after. > > > > Yes. This is clearly where the Pharo platform is showing some innovation > in the ability to shape better object representations. > > > > At the same time, GUI-wise, there is very little innovation in the GUI > language used; GT provides a very limited language, for the sake of > efficiency and ease (*). But maybe it can't be done in another way, if you > want people to really build their extensions. > > > > > > At feenk, we donât say that we build tools. We see ourselves as > designing experiences. > > > > Which is a worthwhile goal. > > > > Regards, > > > > Thierry > > > > (*) Such layers represent a so huge investment anyway, so it may be > unavoidable. > > > > > > Cheers, > > Doru > > > > > > > > > Regards, > > > > > > Thierry > > > > > > > > > Tim > > > > > > Sent from my iPhone > > > > > > On 26 Aug 2017, at 18:38, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > > > > >> > > >> > > >> 2017-08-26 15:44 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > >> No Thierry, Newspeak do not allow it. And it not looks similar to > what I want. > > >> > > >> Hum, you would still get the same overall approach: editor inside > editor (or view inside view). Now, you can say it is not the same, up to > you. > > >> > > >> For me, it has the same effect: the editor isn't in a single place > anymore. You may consider it doesn't matter; IMHO it does matter (and it > makes for me the Newspeak editor slightly less efficient; the same that the > Smalltalk system browser seemed more effective than the Self in-place > method edit, for having used both). > > >> > > >> > > >> Now command+click on selector opens implementors window. In past it > moved browser to single implementor. It was nice and it is how other IDEs > are working. > > >> > > >> You miss the past behaviour? Why not adding it again? > > >> > > >> But as Tim notice it always loses context. And it is quite difficult > to browse long call chain which include many small methods. > > >> > > >> I'm not sure it would solve that one. > > >> > > >> Either it is a long call chain with a fan-out of one, in which case > the developper is creating many useless single line methods because it is > "the right way"(tm), or it has a fan-out greater than one (your typical > polymorphic code) and then each time you open, you have half a dozen > implementors. > > >> > > >> For that, you already have the flow browser. > > >> > > >> So with new editor command+click will be able expand implementor just > in place. I think it will be big improvement for IDE. > > >> > > >> As I said, with Calypso and Nautilus handling badly long methods, > then a method inside a method just makes the top level method longer... I'd > like to see you do that on Metacello or SmaCC code, where important methods > easily go over 50 lines before you expand anything. > > >> > > >> I'd say there that the GTInspector approach would work better -> > expand on the right, with the ability to keep two side by side, and > overlaid with lines clearly showing what has been expanded (for that > "context" thing). > > >> > > >> Regards, > > >> > > >> Thierry > > >> > > >> > > >> 2017-08-26 14:59 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com > >: > > >> > > >> > > >> 2017-08-26 14:46 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > >> > > >> 2017-08-26 14:31 GMT+02:00 Tim Mackinnon <tim(a)testit.works>: > > >> Denis - that's a very cool idea if I've understood you - expand in > the source code of the current method, literally inline? So you could > scroll up and down to view the context as you expand it out? > > >> > > >> Yes, exactly. > > >> > > >> Then that would look a bit like the NewSpeak code browser, if you > would like to try the concept. > > >> > > >> There are disadvantages to that paradigm. One of those is that the > system browser in Pharo is ill-suited to long methods. > > >> > > >> Thierry > > >> > > >> > > >> One of the complaints around refactoring is that you lose context of > surrounding code - intelligent in place expansion would be the best of both > worlds... > > >> > > >> Tim > > >> > > >> Sent from my iPhone > > >> > > >> On 26 Aug 2017, at 11:40, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > > >> > > >>> This is really cool. It opens so many possibilities. > > >>> > > >>> I imaging method editor where message sends can be expanded to > implementors just in place. > > >>> > > >>> 2017-08-26 1:03 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > > >>> Hi, > > >>> > > >>> We are really pleased to announce another major advancement in the > development of the moldable editor, and most of it was enabled because of > one new feature: expandable elements. We think this will impact > significantly our day to day interactions. > > >>> > > >>> To exemplify what we mean, we will make use of two more alpha > projects that we did not announce yet: GT Documenter (a set of > documentation tools based on Pillar and GT Examples) and GT Mondrian (the > graph visualization engine), both of which are being implemented in Bloc. > > >>> > > >>> Please take a look at the following pictures showing the > documentation Pillar file that ships together with GT Mondrian. What stands > out are the two embedded pictures. These are actually not pictures, but > visualizations rendered live during the viewing of the document out of a > referenced GT Example. > > >>> > > >>> > > >>> > > >>> Now, GT Examples are likely also new for most people. We introduced > them a couple of years ago based on the original idea of Markus Gaelli. > These are a kind of tests that return an object and that can be built out > of other examples. The nice thing is that they are always executable and > testable. So, of course, if you see the resulting object, you can also see > the code that created it, and if you see the code, you can even execute it > live, right in place (notice the preview of the second snippet). > > >>> > > >>> <pillar-mondrian-expanded-preview.png> > > >>> > > >>> Perhaps the most controversial part of GT Examples is that they > offer a mechanism to define static dependencies via pragmas. Please, letâs > leave this debate to another occasion, but please also notice that tools > can use that static information to unfold the code of the referenced method > (notice the nested code editors). > > >>> > > >>> A side note: if you look closer at the list with three items at the > top of the Tutorial section, you will notice numbering next to #. That is > actually syntax highlighting and so is the mechanism that embeds the > expandable elements. Itâs really cool. > > >>> > > >>> Taking step back, when we introduced the editor a few weeks ago, we > called it moldable because we said we can make it take different shapes > easily. GT Documenter with everything you see in the above screenshots has > currently ~500 lines of code, and all this while still having an editor > that is highly scalable. > > >>> > > >>> We think that Bloc and Brick will change dramatically face of Pharo > and now we can start to get a glimpse of what is possible. For example, the > use case presented above is more than a technical tool, and we think this > will change both the way we write documentation and the way we consume it. > > >>> > > >>> All these will be presented at ESUG both during presentations and at > the Innovation Awards competition. In the meantime, those that want to play > with it can execute the following in both Pharo 6.1 and Pharo 7.0: > > >>> > > >>> Iceberg enableMetacelloIntegration: true. > > >>> Metacello new > > >>> baseline: 'GToolkit'; > > >>> repository: 'github://feenkcom/gtoolkit/src'; > > >>> load. > > >>> > > >>> And then inspect: > > >>> './pharo-local/iceberg/feenkcom/gtoolkit/doc/mondrian/index.pillar' > asFileReference > > >>> > > >>> Cheers, > > >>> The feenk team > > >>> > > >>> -- > > >>> www.tudorgirba.com > > >>> www.feenk.com > > >>> > > >>> "Innovation comes in the least expected form. > > >>> That is, if it is expected, it already happened." > > >>> > > >>> > > >> > > >> > > >> > > >> > > > > > > > -- > > www.tudorgirba.com > > www.feenk.com > > > > "Problem solving efficiency grows with the abstractness level of problem > understanding." > > -- > www.tudorgirba.com > www.feenk.com > > "Innovation comes in the least expected form. > That is, if it is expected, it already happened." > > >

Aug. 27, 2017

Re: [Pharo-users] Copy bitmap to clipboard

by Peter UhnÃ¡k

I don't know about other platforms, but on linux the clipboard is implemented in this 8kloc C file https://github.com/pharo-project/pharo-vm/blob/e0ce2d9d78c3c7b37bbc12cd8730… e.g. getting the selection https://github.com/pharo-project/pharo-vm/blob/d06aa80a38bc1b6d1f4cc54301ec… >From the comments around the code I gather that the author(s) were aware that images can be copied around in clipboard. Whether it actually works I do no know. (it would be if the clipboard-related code wrote itself into a nice separate file/plugin :)) Peter On Thu, Jun 15, 2017 at 4:00 PM, Hilaire <hilaire(a)drgeo.eu> wrote: > Hi, > > A Dr. Geo user asked me about copying a DrGeo canvas view in the system > clipboard, to past it in other tools as a text writer or any other > editing tool. > > I looked in Pharo3 and Pharo6, I found text clipboard operation but it > is not clear if there is support for other format? > > What about > primAddClipboardData:data:dataFormat: > > I would like to copy and paste the DrGeo canvas as PNG content. > > -- > Dr. Geo > http://drgeo.eu > > >

Aug. 27, 2017

Re: [Pharo-users] The Spec UI Framework. first translation to korean finish.

by Stephane Ducasse

Hi peter Tx for the translation. I'm about to make sure that travis will build automatically the spec book via a docker container. Have a look at booklet-Smacc to see what I mean: each time you commit to the repository, the build is done and it is latex via a docket file and the pdf store on binTray. So I do not know how to produce a korean pdf with latex but if you should us we could convert your translations and store them in square brackets associates in git hub. Stef On Sat, Aug 26, 2017 at 10:51 PM, peter yoo <onionmixer(a)gmail.com> wrote: > hello. for pharo guys. Long time no see. > > It is not easy for Korean people to study pharo. Very few people use > smalltalk. Of course, it is hard to find Korean language resources. > > Recently I went to find the spec framework to study Pharo. Of course I > looked at morphic designer in squeak, but I believe in pharo team. > > I have translated it with the help of google for those who want to study. I > refer to the pillar source of git. I wanted to work with pdf, but I know > xetex, but I do not know about pillar and luatex. So I put it on the wiki. > > Thank you for always making good pharo. > > > http://trans.onionmixer.net/mediawiki/index.php?title=TheSpecUIframework > > -- > http://lookandwalk.com http://looknw.com | http://onionmixer.net > peter yoo(Jonghwa Yoo). ROK

Aug. 27, 2017

Re: [Pharo-users] [ann] moldable editor - with expandable elements

by Tudor Girba

Hi Thierry, Indeed, you noticed correctly that we stayed away from the code browser. We found several years ago that Morphic was too limiting. During the Spotter implementation we found ourselves having to construct a mini-Morphic in order to do what we wanted to do. With text we had several prototypes for a different kind of editing experience, but we hit a wall. The interface from the GTInspector is the most rudimentary solution we could put in place, and it is there mostly as a placeholder to get over the bridge. This is why we joined the Bloc project and we focused all our tool development effort on it. The goal is to be able to build interfaces that do not yet exist and that enable workflows that are radically different. We showed can do that once we have an infrastructure, and we will continue to do it until we have a full development experience. We did not start from the experience of writing code explicitly. That is because the IDE should encompass all activities including the way we understand a system, and we think that focusing on reading is to be left for the previous century. So, we started from the inspector and debugger and we are making our way towards the writing part. Writing code is certainly of deep interest to us. However, the system browser is the least interesting of the places where we want to write code. That is because we want to code against live objects, not against dead text. The main use case the system browser is good for is to organize code and to find a starting place for getting to a living object. For the rest of the use cases, there are other solutions that are better. For example, even with the current Playground, we have people spending more time in there than in the code browser. That says something given that the Playground is quite bare at the moment. We do not think in terms of tools, but the overall workflows we want to support. Itâs not a race against features, but a reimagining of what an experience can be like. For example, letâs take documentation: right now, both producing and consuming documentation happens mostly outside of the environment. So, the I in the IDE is failing in this respect. We want to make both of these activities more attractive inside the environment and the demo you see here is a step in that direction. There is no name for this tool yet because we tend to not phrase the problem like that. Related to other editors, there are indeed WYSWIG tools, but they are typically not dynamic. There are viewers that are dynamic, but they tend to not scale well and not be editable. There are tools that scale, but they are not too visual. And even when there exist some, they are not in an IDE. So, yes, there are pieces that already exist, but the way we apply them is novel. As for syntax highlighting, it is tied to text and attributes but only to the extent we wanted it to be. The current implementation is 2k lines of code. In comparison, just the core of Rubric is 5.5k. But, the rendering is not related to text whatsoever. Word and adornments are just element that conform to a layout. So, this means that people can build something else at a much smaller costs should they want to. Cheers, Doru > On Aug 27, 2017, at 10:43 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Hi Doru, > > 2017-08-27 9:24 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > > On Aug 27, 2017, at 12:06 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > > Hi Tim, > > > > 2017-08-26 23:27 GMT+02:00 Tim Mackinnon <tim(a)testit.works>: > > I think you pose some interesting design challenges - but it's worthy of experimentation. > > > > I share Denis' enthusiasm to build something better - but it's true it's not an easy problem space. > > > > I'm a big fan of GTInspector, but sometimes I slide across and lose my context (not always, and not for all types of problems). > > > > I think you may be on the key issue, the loss of context when navigating through the code. In the 90's, that was called the 'lost in hyperspace' problem linked with hypertexts and hypermedia. > > > > I'm not sure it was ever resolved (I stopped following that research community during my PhD), apart from considering that google solved it for the web. At least, this would be the choice made by Newspeak: consider that the code is like the web, and build a system web browser. > > > > > > For unique extractions - inlining is a no brainer (it's just like code folding in many editors). For non-unique, maybe something in the gutter might let you easily flip... I don't know, but I'm not convinced our current way is always optimal. > > > > Agreed. I have changed the way I code to reduce the context needed to understand it. > > > > > > Still, the whole moldable idea is to make it easy to experiment - and that's the cool bit. That's where we thrive. > > > > Smalltalk has allways been open to that sort of experiment. The moldable bit may make it easier, or at least not more complex than it was when Smalltalk systems were a lot smaller. Now, is that moldable implementation really that free, or has it sacrificed certain freedoms to make moldable things easier? > > Please let me intervene briefly :). > > Smalltalk was always indeed open. However, we noticed that regardless of the application domain, tools essentially looked the same for these systems. All Smalltalkers I asked extended Object at least once, but before the GTInspector, most of them never extended the inspector. Our language was extremely dynamic, but our tools less so. That is a conceptual problem that we address with what we call moldability. > > Hum. From 1992 to now, I would make the same statement in the Smalltalk world, mostly talking a certain conservatism first (look at how much the system browser has evolved over the years), but also some questions about efficiency of alternative forms. > > For example, the code view of the GTInspector remain for me as one of the clumsiest, worse view I've ever seen in the Smalltalk world for editing code. > > > The goal of moldability is to make it inexpensive to customize. To this end, we approach the IDE as a language and the moldability is captured in the operators that language provides. Of course, there are limitations to what can be doable inexpensively. However, it turns out that if you do manage to bring the cost to a radical low cost, you get much more extensions and experimentations going on. > > I'm a bit missing where the moldability of the IDE went, in that context. You seem to stear very clear from anything related to the system browser... > > > All infrastructures make certain things easier and others less so. The value of all this does depend on what are the operators and how deep in the infrastructure they are placed. For example, the moldable editor shows these expandable elements as part of syntax highlighting. Syntax highlighting existed since a long time, so making it also able to show other things is quite powerful and requires nothing hardcoded. In fact, I do not know of any other editor that can do that while still having the performance we get. > > ? Especially that last statement. > > Adding non text elements in an editor has allways been a fairly easy endeavour in ST, as long as I could remember (1993?). > > Performance on long texts is orthogonal to Bloc, right? It is present in all editors that do formatting on long documents since the first WYSIWIG editors appeared in the 80's. > > And, so far, the examples you're showing means that editor isn't as capable as Doc (in 1989/1990?) was. > > I a bit worried about that syntax highlighting approach. It seems to me very tied to a text + attributes representation instead of an object representation, and I find that API in Pharo horribly clumsy and ineffective, for the apparent benefit of slightly reducing object storage size with a kind of RLE compression. > > > But, even more important than tool features is the behavior of people. For example, when we first introduced the inspector, all talk was about details (e.g., how it is clumsy to navigate laterally). 2 years later, at this yearâs PharoDays most talks used the GTInspector in one way or another to exemplify the presentation. This is a significant impact and this is what we are after. > > Yes. This is clearly where the Pharo platform is showing some innovation in the ability to shape better object representations. > > At the same time, GUI-wise, there is very little innovation in the GUI language used; GT provides a very limited language, for the sake of efficiency and ease (*). But maybe it can't be done in another way, if you want people to really build their extensions. > > > At feenk, we donât say that we build tools. We see ourselves as designing experiences. > > Which is a worthwhile goal. > > Regards, > > Thierry > > (*) Such layers represent a so huge investment anyway, so it may be unavoidable. > > > Cheers, > Doru > > > > > Regards, > > > > Thierry > > > > > > Tim > > > > Sent from my iPhone > > > > On 26 Aug 2017, at 18:38, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > >> > >> > >> 2017-08-26 15:44 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> No Thierry, Newspeak do not allow it. And it not looks similar to what I want. > >> > >> Hum, you would still get the same overall approach: editor inside editor (or view inside view). Now, you can say it is not the same, up to you. > >> > >> For me, it has the same effect: the editor isn't in a single place anymore. You may consider it doesn't matter; IMHO it does matter (and it makes for me the Newspeak editor slightly less efficient; the same that the Smalltalk system browser seemed more effective than the Self in-place method edit, for having used both). > >> > >> > >> Now command+click on selector opens implementors window. In past it moved browser to single implementor. It was nice and it is how other IDEs are working. > >> > >> You miss the past behaviour? Why not adding it again? > >> > >> But as Tim notice it always loses context. And it is quite difficult to browse long call chain which include many small methods. > >> > >> I'm not sure it would solve that one. > >> > >> Either it is a long call chain with a fan-out of one, in which case the developper is creating many useless single line methods because it is "the right way"(tm), or it has a fan-out greater than one (your typical polymorphic code) and then each time you open, you have half a dozen implementors. > >> > >> For that, you already have the flow browser. > >> > >> So with new editor command+click will be able expand implementor just in place. I think it will be big improvement for IDE. > >> > >> As I said, with Calypso and Nautilus handling badly long methods, then a method inside a method just makes the top level method longer... I'd like to see you do that on Metacello or SmaCC code, where important methods easily go over 50 lines before you expand anything. > >> > >> I'd say there that the GTInspector approach would work better -> expand on the right, with the ability to keep two side by side, and overlaid with lines clearly showing what has been expanded (for that "context" thing). > >> > >> Regards, > >> > >> Thierry > >> > >> > >> 2017-08-26 14:59 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > >> > >> > >> 2017-08-26 14:46 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> > >> 2017-08-26 14:31 GMT+02:00 Tim Mackinnon <tim(a)testit.works>: > >> Denis - that's a very cool idea if I've understood you - expand in the source code of the current method, literally inline? So you could scroll up and down to view the context as you expand it out? > >> > >> Yes, exactly. > >> > >> Then that would look a bit like the NewSpeak code browser, if you would like to try the concept. > >> > >> There are disadvantages to that paradigm. One of those is that the system browser in Pharo is ill-suited to long methods. > >> > >> Thierry > >> > >> > >> One of the complaints around refactoring is that you lose context of surrounding code - intelligent in place expansion would be the best of both worlds... > >> > >> Tim > >> > >> Sent from my iPhone > >> > >> On 26 Aug 2017, at 11:40, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > >> > >>> This is really cool. It opens so many possibilities. > >>> > >>> I imaging method editor where message sends can be expanded to implementors just in place. > >>> > >>> 2017-08-26 1:03 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > >>> Hi, > >>> > >>> We are really pleased to announce another major advancement in the development of the moldable editor, and most of it was enabled because of one new feature: expandable elements. We think this will impact significantly our day to day interactions. > >>> > >>> To exemplify what we mean, we will make use of two more alpha projects that we did not announce yet: GT Documenter (a set of documentation tools based on Pillar and GT Examples) and GT Mondrian (the graph visualization engine), both of which are being implemented in Bloc. > >>> > >>> Please take a look at the following pictures showing the documentation Pillar file that ships together with GT Mondrian. What stands out are the two embedded pictures. These are actually not pictures, but visualizations rendered live during the viewing of the document out of a referenced GT Example. > >>> > >>> > >>> > >>> Now, GT Examples are likely also new for most people. We introduced them a couple of years ago based on the original idea of Markus Gaelli. These are a kind of tests that return an object and that can be built out of other examples. The nice thing is that they are always executable and testable. So, of course, if you see the resulting object, you can also see the code that created it, and if you see the code, you can even execute it live, right in place (notice the preview of the second snippet). > >>> > >>> <pillar-mondrian-expanded-preview.png> > >>> > >>> Perhaps the most controversial part of GT Examples is that they offer a mechanism to define static dependencies via pragmas. Please, letâs leave this debate to another occasion, but please also notice that tools can use that static information to unfold the code of the referenced method (notice the nested code editors). > >>> > >>> A side note: if you look closer at the list with three items at the top of the Tutorial section, you will notice numbering next to #. That is actually syntax highlighting and so is the mechanism that embeds the expandable elements. Itâs really cool. > >>> > >>> Taking step back, when we introduced the editor a few weeks ago, we called it moldable because we said we can make it take different shapes easily. GT Documenter with everything you see in the above screenshots has currently ~500 lines of code, and all this while still having an editor that is highly scalable. > >>> > >>> We think that Bloc and Brick will change dramatically face of Pharo and now we can start to get a glimpse of what is possible. For example, the use case presented above is more than a technical tool, and we think this will change both the way we write documentation and the way we consume it. > >>> > >>> All these will be presented at ESUG both during presentations and at the Innovation Awards competition. In the meantime, those that want to play with it can execute the following in both Pharo 6.1 and Pharo 7.0: > >>> > >>> Iceberg enableMetacelloIntegration: true. > >>> Metacello new > >>> baseline: 'GToolkit'; > >>> repository: 'github://feenkcom/gtoolkit/src'; > >>> load. > >>> > >>> And then inspect: > >>> './pharo-local/iceberg/feenkcom/gtoolkit/doc/mondrian/index.pillar' asFileReference > >>> > >>> Cheers, > >>> The feenk team > >>> > >>> -- > >>> www.tudorgirba.com > >>> www.feenk.com > >>> > >>> "Innovation comes in the least expected form. > >>> That is, if it is expected, it already happened." > >>> > >>> > >> > >> > >> > >> > > > > -- > www.tudorgirba.com > www.feenk.com > > "Problem solving efficiency grows with the abstractness level of problem understanding." -- www.tudorgirba.com www.feenk.com "Innovation comes in the least expected form. That is, if it is expected, it already happened."

Aug. 27, 2017