- Pharo-users - lists.pharo.org

Re: [Pharo-users] problem with FLMaterializer

by Cyril Ferlicot

On sam. 5 aoÃ»t 2017 at 13:10, Johannes Brauer <brauer(a)nordakademie.de> wrote: > Peter > > Your suggestion is correct. I correct the expression to > > (FLMaterializer materializeFromFileNamed: aFileRefence *fullName*) > > Now I get another exception. > KeyNotFound: key #'ositive8SmallIntegerClusterJ 4Ã 1â Ã°+ â( %? "< 9 Âª 6P M > Â¾0 d *ÃD ''x ! Å 8' not found in SystemDictionary > I think this is a compatibility problem between different Fuel versions. > Hi, If you use Fuel to serialize objects with Pharo 4, then you can only materialize them with a Fuel from Pharo 4. Other versions of Fuel will not be able to read them. > Johannes > > -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Aug. 5, 2017

Re: [Pharo-users] problem with FLMaterializer

by Johannes Brauer

Peter Your suggestion is correct. I correct the expression to (FLMaterializer materializeFromFileNamed: aFileRefence fullName) Now I get another exception. KeyNotFound: key #'ositive8SmallIntegerClusterJ4Ã1âÃ°+â( %?Â"<9Âª6PMÂ¾0d*ÃD ''x!Å8' not found in SystemDictionary I think this is a compatibility problem between different Fuel versions. Johannes Am 05.08.2017 um 11:13 schrieb PBKResearch <peter(a)pbkresearch.co.uk<mailto:peter@pbkresearch.co.uk>>: Johannes Just a suggestion: FLMaterializer class >>materializeFromFileNamed: requires as argument aFilename, not aFileRefence. Presumably this means the name as a string. This makes sense, because #convertToWithConverter: is the name of a method understood by strings. If your invocation of the materializer includes asFileReference, try again without that. Hope this helps Peter Kenny From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Johannes Brauer Sent: 04 August 2017 23:56 To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org<mailto:pharo-users@lists.pharo.org>> Subject: [Pharo-users] problem with FLMaterializer Hi everyone, trying to migrate a Seaside application from Pharo4 to Pharo6 I get a problem with FLMaterializer. An expression like (FLMaterializer materializeFromFileNamed: aFileRefence) results in MessageNotUnderstood: FileReference>>convertToWithConverter: The same file can be materialized in Pharo4 without problems. Johannes

Aug. 5, 2017

Re: [Pharo-users] problem with FLMaterializer

by PBKResearch

Johannes Just a suggestion: FLMaterializer class >>materializeFromFileNamed: requires as argument aFilename, not aFileRefence. Presumably this means the name as a string. This makes sense, because #convertToWithConverter: is the name of a method understood by strings. If your invocation of the materializer includes asFileReference, try again without that. Hope this helps Peter Kenny From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Johannes Brauer Sent: 04 August 2017 23:56 To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Subject: [Pharo-users] problem with FLMaterializer Hi everyone, trying to migrate a Seaside application from Pharo4 to Pharo6 I get a problem with FLMaterializer. An expression like (FLMaterializer materializeFromFileNamed: aFileRefence) results in MessageNotUnderstood: FileReference>>convertToWithConverter: The same file can be materialized in Pharo4 without problems. Johannes

Aug. 5, 2017

Best Practices for Bundling Documentation

by Evan Donahue

Hello, I'm working on cleaning up a couple of projects for release, and I was wondering what the best practices were for including appropriate documentation with projects. Should I just drop a text blob in a prominent class comment? Is there a tool for structuring documentation? Is documentation typically kept separate from the code? Seems natural to include it so you never have to leave the image, but I'm not sure what most people do. Thanks, Evan

Aug. 5, 2017

problem with FLMaterializer

by Johannes Brauer

Hi everyone, trying to migrate a Seaside application from Pharo4 to Pharo6 I get a problem with FLMaterializer. An expression like (FLMaterializer materializeFromFileNamed: aFileRefence) results in MessageNotUnderstood: FileReference>>convertToWithConverter: The same file can be materialized in Pharo4 without problems. Johannes

Aug. 4, 2017

[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