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

[ann] moldable brick editor - alpha

by Tudor Girba

Hi, We are very happy to announce the alpha version of a moldable editor built in Brick (https://github.com/pharo-graphics/Brick) which is based on Bloc (https://github.com/pharo-graphics/Bloc) This is primarily the work of Alex Syrel. The project was initially financially sponsored by ESUG and it is currently supported by feenk. And of course, the project is based on the tremendous work that went into Bloc and Brick by all contributors. Take a look at this 2 min video: https://www.youtube.com/watch?v=2vy6VMJM9W4&feature=youtu.be The basic editor works and it is both flexible and scalable. For example, the last example shown in the video is an editor opened on 1M characters, which is reasonably large, and as can be seen see one can interact with it as smoothly as with the one screen text. It actually works just as fine with 100M characters. The functionality of the editor includes: rendering, line wrapping, keypress and shortcut handling, navigation, selection and text styling. Currently, the editor is 1260 lines of code including method and class comments. This is not large for a text editor and this is possible because most of the work is done by generic concepts that already exist in Bloc such as layouts and text measurements. Beside the small maintenance cost, the benefit is that we have the option to build all sorts of variations with little effort. That is why we call this a moldable text editor. Another benefit of using elements and layouts is that we can also embed other kinds of non-text elements with little effort (such as pictures), and obtain a rich and live text editor. We already have basic examples for this behavior, and we will focus more in the next period on this area. The next immediate step is to add syntax highlighting. Beside the text attributes problem, this issue will also exercise the thread-safety the implementation is. The underlying structure (https://en.wikipedia.org/wiki/Rope_(data_structure)) is theoretically thread-safe, but it still needs to be proven in practice. We think this is a significant step because the editor was the main piece missing in Brick and it will finally allow us to build value that can be directly perceived by regular users on top of Brick and this, in turn, will generate more traction. Please also note that because now Bloc is directly embeddable in Morphic it means that we can actually start using it right away. For example, the picture below shows the text element being shown through a live preview in the GTInspector. This is another puzzle piece towards the final goal of engineering the future of the Pharo user interface. There is still a long way to go to reach that goal, but considering the work that is behind us, that goal that looked so illusive when Alain and Stef initiated the Bloc project is now palpable. We will continue the work on this over the next period and we expect to announce new developments soon. If you want to play with it, you can load the code like this (works in both Pharo 6 and 7): Iceberg enableMetacelloIntegration: true. Metacello new baseline: 'Brick'; repository: 'github://pharo-graphics/Brick/src'; load: #development Please let us know what you think. Cheers, Alex and Doru -- www.tudorgirba.com www.feenk.com "What is more important: To be happy, or to make happy?"

Aug. 4, 2017

Re: [Pharo-users] Threads safety in Pharo

by Stephane Ducasse

On Fri, Aug 4, 2017 at 7:06 PM, Alidra Abdelghani via Pharo-users < pharo-users(a)lists.pharo.org> wrote: > > > ---------- Forwarded message ---------- > From: Alidra Abdelghani <alidrandco(a)yahoo.fr> > To: Guillermo Polito <guillermopolito(a)gmail.com> > Cc: Any question about pharo is welcome <pharo-users(a)lists.pharo.org>, > "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr>, farid arfi < > arfi_f(a)hotmail.com> > Bcc: > Date: Fri, 4 Aug 2017 19:06:00 +0200 > Subject: Re: [Pharo-users] Threads safety in Pharo > Thanks Guille for your answer, > From what I understand, it is mainly a synchronisation problem. Why cant' > existing synchronisation mechanisms (semaphores and mutex) be used? > They can but it means to analyse existing code and produce thread safe one. > Abdelghani > > > On 31 Jul 2017, at 18:44, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > I believe there is no such a document. It would be however interesting to > investigate it a bit deeper. In general, the problem we talk about when we > talk about thread safety is the following: Can we run a workspace in a > separate thread than a browser and provide correct results? Can we run two > browsers concurrently and change code from both of them? > > The thread safety problem has several levels I'd say: > > - the kernel of the language (classes, methods, compilation, and so on) > cannot safely be modified while other threads are running. Thus, if we > compile a new version of a method in a thread, that could break a separate > thread that was using that method. > > - there are several libraries using global state. We should investigate > if they work correctly when using them concurrently. > E.g., source code management is not thread safe. This could cause a > source code corruption if several methods are modified concurrently. > Like that, we sh n ould investigate all libraries and see what should > be adapted and if there is a need at all. > > > - in a third level, general core libraries (collections, networking, > files, etc) are not designed to be thread safe and that is natural. For > example, most of the time you don't want that your collection is accessed > concurrently. For such cases, some libraries could provide some > extensions/wrappers/whatsoever to provide some synchronization mechanism. > Otherwise it is the responsibility of the user to synchronize usages with > semaphores/mutexes. > > > On Mon, Jul 31, 2017 at 1:38 AM, Alidra Abdelghani via Pharo-users < > pharo-users(a)lists.pharo.org> wrote: > >> >> >> ---------- Forwarded message ---------- >> From: Alidra Abdelghani <alidrandco(a)yahoo.fr> >> To: pharo-users(a)lists.pharo.org >> Cc: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr>, farid arfi < >> arfi_f(a)hotmail.com> >> Bcc: >> Date: Mon, 31 Jul 2017 01:38:58 +0200 >> Subject: Threads safety in Pharo >> Hi, >> >> Somebody once evoked the problem of threads safety in Pharo. With a >> friend of mine who is expert in formal methods and process scheduling, we >> would like to have a look on it. >> Does anyone knows a good document describing the problem of Pharo with >> threads safety or at least any document that we can start with? >> >> Thanks in advance, >> Abdelghani >> >> >> >> > > > -- > > Guille Polito > > Research Engineer > French National Center for Scientific Research - *http://www.cnrs.fr* > <http://www.cnrs.fr/> > > > *Web:* *http://guillep.github.io* <http://guillep.github.io/> > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> > > > >

Aug. 4, 2017

Re: [Pharo-users] Threads safety in Pharo

by Stephane Ducasse

> > Great, I taught some of theses concepts to my students some times ago and we did some fun lab sessions with the Linux scheduler > > This was on my todo to turn it into a book chapter for Pharo. > > So may be we could work together to write a little booklet on this aspect to get started. > > > I would love to :D Be my guest. I can create a booklet in no time. I once started to collect notes on PharoLimbo/ConcurrencyBasics on github. Start there! Stef > > > Stef > > >

Aug. 4, 2017

Re: [Pharo-users] Compiling lots of method source without debugger

by Stephane Ducasse

Hi Patrick Welcome :) > Hello everyone, > > This is my first time here so I hope this is the right place to ask > questions. Yes it is. > In an attempt to move lots of code from VA Smalltalk to Pharo, I need to > compile a lot of methods whose code may or may not work due to missing > classes in Pharo etc. > I want to be able to compile these methods programatically without > interruptions (using method source strings only) and gather all compiler > errors that occur. What would be the best way to go about this? The compiler insfrastructure should be improved to stop "logging" error by writing on the Transcript but instead produce tractable objects representing error (shadowing...). But this is not there yet. To support your task and other scenario we worked on UndefinedClasses The idea is to be able to load a class even if its superclass does not exist and without losing information. MCHttpRepository location: 'http://smalltalkhub.com/mc/StephaneDucasse/PetitsBazars/main' user: '' password: '' Package UndefinedClasses Let us know. We did several iterations but this may be still green. > Also: How do I control in which package a compiled method ends up if the > target class is in a different package (Method extension)? In pharo the importer is based on *AAA => method in package AAA > Any help would be greatly appreciated! Another pattern that I used to load several versions of squeak into VisualWorks a while ago was: Capturing exceptions Walking the stack to extract information Compile on the fly the superclas Resume Now if you have a lot of code to load, may be it is worth to extend/modify the parser/compiler to raise better exceptions. If you do so, please let us know because we can introduce your hook in Pharo. Marcus is on vacation until 21 of August. Any feedback to support better your scenario is precious to us. Now we did not get the incentive to push too much (besides the UndefinedClasses), but it is the occasion. Stef > > Kind regards, > Patrick Scherer

Aug. 4, 2017

Re: [Pharo-users] Compiling lots of method source without debugger

by Peter Uhnak

Hi, > This is my first time here so I hope this is the right place to ask > questions. It is. :) > I want to be able to compile these methods programatically without > interruptions (using method source strings only) and gather all compiler > errors that occur. What would be the best way to go about this? It is certainly a way. Compilation errors will raise SyntaxErrorNotifications that you can capture, e.g. sthClass := Object subclass: #Something. [ sthClass compile: '^^' classified: 'protocol-name' ] on: SyntaxErrorNotification do: [ :err | err inspect ] > Also: How do I control in which package a compiled method ends up if the > target class is in a different package (Method extension)? Methods are stored in protocols (accessing, initialization, as yet unclassified). If you however start the name with an asterisk *, then the method will become an extension method and will be stored in the package name following the asterisk. e.g. sthClass := Object subclass: #Something. sthClass compile: 'methodName self lives somewhere else' classified: '*SomewhereElse'. > > Any help would be greatly appreciated! I would (shameless self-promotion) also recommend looking at this https://github.com/peteruhnak/pharo-changes-builder , so you could review the changes before actually compiling them. Peter

Aug. 4, 2017

Re: [Pharo-users] Threads safety in Pharo

by Alidra Abdelghani

Thanks Guille for your answer, >From what I understand, it is mainly a synchronisation problem. Why cant' existing synchronisation mechanisms (semaphores and mutex) be used? Abdelghani > On 31 Jul 2017, at 18:44, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > I believe there is no such a document. It would be however interesting to investigate it a bit deeper. In general, the problem we talk about when we talk about thread safety is the following: Can we run a workspace in a separate thread than a browser and provide correct results? Can we run two browsers concurrently and change code from both of them? > > The thread safety problem has several levels I'd say: > > - the kernel of the language (classes, methods, compilation, and so on) cannot safely be modified while other threads are running. Thus, if we compile a new version of a method in a thread, that could break a separate thread that was using that method. > > - there are several libraries using global state. We should investigate if they work correctly when using them concurrently. > E.g., source code management is not thread safe. This could cause a source code corruption if several methods are modified concurrently. > Like that, we sh n ould investigate all libraries and see what should be adapted and if there is a need at all. > > - in a third level, general core libraries (collections, networking, files, etc) are not designed to be thread safe and that is natural. For example, most of the time you don't want that your collection is accessed concurrently. For such cases, some libraries could provide some extensions/wrappers/whatsoever to provide some synchronization mechanism. Otherwise it is the responsibility of the user to synchronize usages with semaphores/mutexes. > > > On Mon, Jul 31, 2017 at 1:38 AM, Alidra Abdelghani via Pharo-users <pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org>> wrote: > > > ---------- Forwarded message ---------- > From: Alidra Abdelghani <alidrandco(a)yahoo.fr <mailto:alidrandco@yahoo.fr>> > To: pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org> > Cc: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr <mailto:stephane.ducasse@inria.fr>>, farid arfi <arfi_f(a)hotmail.com <mailto:arfi_f@hotmail.com>> > Bcc: > Date: Mon, 31 Jul 2017 01:38:58 +0200 > Subject: Threads safety in Pharo > Hi, > > Somebody once evoked the problem of threads safety in Pharo. With a friend of mine who is expert in formal methods and process scheduling, we would like to have a look on it. > Does anyone knows a good document describing the problem of Pharo with threads safety or at least any document that we can start with? > > Thanks in advance, > Abdelghani > > > > > > > -- > > Guille Polito > > Research Engineer > French National Center for Scientific Research - http://www.cnrs.fr <http://www.cnrs.fr/> > > > Web: http://guillep.github.io <http://guillep.github.io/> > Phone: +33 06 52 70 66 13

Aug. 4, 2017

How to remove packages and reclaim image size?

by Tim Mackinnon

Hi - Iâm wondering how you best remove packages in the image to reclaim space? I am a bit confused because I see 2 package systems MCPackage and RPackage? And I see 2 different ways of removing things: (MCPackage named: name) unload (RPackage organizer packageNamed: name) unregister So which is the correct one to use (or are they the same?). Iâve tried both, but then when I save my image (headless in a script) - it doesnât seem to make any difference in image size. So Iâm also wondering if there is an extra step to forcing size reduction. I have tried: 3 timesRepeat: [ Smalltalk garbageCollect. Smalltalk cleanOutUndeclared. Smalltalk fixObsoleteReferences]. Which is what I saw in some ImageCleaner tool, but again I donât see any image size difference, which makes me wonder if Iâm doing the wrong thing or missing a step? Tim

Aug. 4, 2017

Re: [Pharo-users] Glorp reconnection management (was: Re: Glorp: how to reconnect after image shutdown / load?)

by Pierce Ng

On Thu, Aug 03, 2017 at 03:27:16PM +0200, Herby VojÄÃk wrote: > Looking at state of the art code: > GlorpSession >> loginIfError: aBlock > | result | > result := self accessor loginIfError: aBlock. > system platform characterEncoding: accessor encoding. > ^result In the line "result := self accessor loginIfError: aBlock", "self accessor" is not an instance of DatabaseAccessor, because DatabaseAccessor>>loginIfError: aBlock self subclassResponsibility "self accessor" is an instance of PharoDatabaseAccessor, and PharoDatabaseAccessor>>loginIfError: aBlock self log: 'Login'. self databaseDriver: self connectionClass new. self execute: [ self databaseDriver connect: currentLogin. currentLogin secure ifTrue: [ currentLogin discardPassword ] ] ifError: aBlock. self log: 'Login finished' PharoDatabaseAccessor>>isLoggedIn self databaseDriver ifNil: [^ false]. ^ self databaseDriver isConnected Connecting to my instance of Reddit (actually RedditSt20 using SQLite not PostgreSQL), adding a link and then clicking refresh, Transcript shows: Login Login finished SELECT t1.id, t1.url, t1.title, t1.created, t1.points FROM REDDIT_LINKS t1 ORDER BY t1.points DESC LIMIT 20 an OrderedCollection() SELECT t1.id, t1.url, t1.title, t1.created, t1.points FROM REDDIT_LINKS t1 ORDER BY t1.created DESC LIMIT 20 an OrderedCollection() Begin Transaction INSERT INTO REDDIT_LINKS (url,title,created,points) VALUES (?,?,?,?) an Array('http://planet.smalltalk.org' 'Planet Smalltalk' 2017-08-04T22:25:14.558667+08:00 0) SELECT last_insert_rowid() (0.0 s) Commit Transaction SELECT t1.id, t1.url, t1.title, t1.created, t1.points FROM REDDIT_LINKS t1 ORDER BY t1.points DESC LIMIT 20 an OrderedCollection() SELECT t1.id, t1.url, t1.title, t1.created, t1.points FROM REDDIT_LINKS t1 ORDER BY t1.created DESC LIMIT 20 an OrderedCollection() Login happened once. Clicking "New Session": Logout Logout finished Login Login finished SELECT t1.id, t1.url, t1.title, t1.created, t1.points FROM REDDIT_LINKS t1 ORDER BY t1.points DESC LIMIT 20 an OrderedCollection() SELECT t1.id, t1.url, t1.title, t1.created, t1.points FROM REDDIT_LINKS t1 ORDER BY t1.created DESC LIMIT 20 an OrderedCollection() Clicking "Refresh" in the application: SELECT t1.id, t1.url, t1.title, t1.created, t1.points FROM REDDIT_LINKS t1 ORDER BY t1.points DESC LIMIT 20 an OrderedCollection() SELECT t1.id, t1.url, t1.title, t1.created, t1.points FROM REDDIT_LINKS t1 ORDER BY t1.created DESC LIMIT 20 an OrderedCollection() Pierce

Aug. 4, 2017

Re: [Pharo-users] Threads safety in Pharo

by Alidra Abdelghani

> On 01 Aug 2017, at 09:36, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > To complement. > > What would be fun is to investigate the implementation of ProcessScheduler, Process and check the implementation. > > Abdel there is a nice presentation of the processor and process in the Squeak french book. Great, I taught some of theses concepts to my students some times ago and we did some fun lab sessions with the Linux scheduler > This was on my todo to turn it into a book chapter for Pharo. > > So may be we could work together to write a little booklet on this aspect to get started. I would love to :D > > Stef

Aug. 4, 2017

Re: [Pharo-users] Threads safety in Pharo

by Alidra Abdelghani

Hi Ben, > On 01 Aug 2017, at 13:31, Ben Coman <btc(a)openinworld.com> wrote: > > Not sure I'll have what you're looking for, but to start, do you mean Pharo's green threads or vm native threads? I believe this is about Pharo threads. I am not quite sure of what the vm native threads are or if there is a safety problem with them. But still, it could be interesting to investigate :) Thanks Abdelghani > cheers -ben > > On Mon, Jul 31, 2017 at 7:38 AM, Alidra Abdelghani via Pharo-users <pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org>> wrote: > > > ---------- Forwarded message ---------- > From: Alidra Abdelghani <alidrandco(a)yahoo.fr <mailto:alidrandco@yahoo.fr>> > To: pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org> > Cc: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr <mailto:stephane.ducasse@inria.fr>>, farid arfi <arfi_f(a)hotmail.com <mailto:arfi_f@hotmail.com>> > Bcc: > Date: Mon, 31 Jul 2017 01:38:58 +0200 > Subject: Threads safety in Pharo > Hi, > > Somebody once evoked the problem of threads safety in Pharo. With a friend of mine who is expert in formal methods and process scheduling, we would like to have a look on it. > Does anyone knows a good document describing the problem of Pharo with threads safety or at least any document that we can start with? > > Thanks in advance, > Abdelghani > > > >

Aug. 4, 2017