- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Holidays] 14 days no updates: 14th to end of July

by Sven Van Caekenberghe

> On 08 Jul 2016, at 21:04, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Have fun dear integrators! :) +10 >> On 08 Jul 2016, at 19:57, stepharo <stepharo(a)free.fr> wrote: >> >> Hi marcus >> >> I will see if the temperature forces me to stay inside after afternoon naps and before jumping in water. >> In such case I will looks at easy fixes. >> But I will not do it regularly. I will probably have a look the week of 20 and take a real break from tomorrow to end of next week. >> >> Stef >>> Hi, >>> >>> We just saw that everyone who can press the button for a final integration >>> will be on Holidays from July 14 to the end of the month. >>> >>> This means there will be no update, but the issue tracker will stay open of course, >>> so issues can be submitted, fixed and reviewedâ¦ they will just not end up the downloadable >>> image for that 2 weeks. >>> >>> Marcus >>> >> >> > >

July 8, 2016

Re: [Pharo-dev] [Holidays] 14 days no updates: 14th to end of July

by Yuriy Tymchuk

Have fun dear integrators! :) > On 08 Jul 2016, at 19:57, stepharo <stepharo(a)free.fr> wrote: > > Hi marcus > > I will see if the temperature forces me to stay inside after afternoon naps and before jumping in water. > In such case I will looks at easy fixes. > But I will not do it regularly. I will probably have a look the week of 20 and take a real break from tomorrow to end of next week. > > Stef >> Hi, >> >> We just saw that everyone who can press the button for a final integration >> will be on Holidays from July 14 to the end of the month. >> >> This means there will be no update, but the issue tracker will stay open of course, >> so issues can be submitted, fixed and reviewedâ¦ they will just not end up the downloadable >> image for that 2 weeks. >> >> Marcus >> > >

July 8, 2016

Re: [Pharo-dev] [Holidays] 14 days no updates: 14th to end of July

by stepharo

Hi marcus I will see if the temperature forces me to stay inside after afternoon naps and before jumping in water. In such case I will looks at easy fixes. But I will not do it regularly. I will probably have a look the week of 20 and take a real break from tomorrow to end of next week. Stef > Hi, > > We just saw that everyone who can press the button for a final integration > will be on Holidays from July 14 to the end of the month. > > This means there will be no update, but the issue tracker will stay open of course, > so issues can be submitted, fixed and reviewedâ¦ they will just not end up the downloadable > image for that 2 weeks. > > Marcus >

July 8, 2016

Spec Tutorial First chapter

by stepharo

Hi Johan Fabry is writing a great tutorial (and this is cool to see all the material I gathered or wrote with him in the past) to take such great form. I attached the first chapter. I will post the chapter one by one once I review them (so far I have nothing to do - great feeling). Well done Johan! Stef

July 8, 2016

Re: [Pharo-dev] Sound on Debian

by Dimitris Chloupis

Was not able to make it work in Ubuntu either, for me it work only on MacOS On Fri, Jul 8, 2016 at 5:54 PM jannik laval <jannik.laval(a)gmail.com> wrote: > Hi pharoers, > > I just tried sounds on phratch on Debian 8. It returns this message: > > sound_Start(default) > soundStart: snd_add_pcm_handler: Fonction non implantÃ©e > > Is it a problem known ? > > Here is my configuration: > > Image > ----- > /usr/lib/Phratch/shared/Pharo4.0.image > Pharo4.0 > Latest update: #40626 > Unnamed > > Virtual Machine > --------------- > /usr/lib/Phratch/bin/pharo > NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid: > acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 > NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: > acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 > https://github.com/pharo-project/pharo-vm.git Commit: > ed4a4f59208968a21d82fd2406f75c2c4de558b2 Date: 2014-05-15 18:23:04 +0200 > By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14826 > > Unix built on May 15 2014 18:29:39 Compiler: 4.6.3 > VMMaker versionString https://github.com/pharo-project/pharo-vm.git > Commit: ed4a4f59208968a21d82fd2406f75c2c4de558b2 Date: 2014-05-15 18:23:04 > +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14826 > NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid: > acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 > NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: > acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 > > > Cheers, > -- > ~~Jannik Laval~~ > Enseignant-chercheur > Responsable PÃ©dagogique Licence Coordonnateur de Projet en SystÃ¨me > d'Information > IUT LumiÃ¨re, UniversitÃ© Lyon LumiÃ¨re > laboratoire DISP > http://www.jannik-laval.eu > http://www.phratch.com > http://www.approchealpes.info >

July 8, 2016

Re: [Pharo-dev] Having comments for pragma?

by Richard Sargent

Tudor Girba-2 wrote > Hi, > >> On Jun 27, 2016, at 7:55 PM, Eliot Miranda < > eliot.miranda@ > > wrote: >> >> Hi Doru, >> >> On Mon, Jun 27, 2016 at 6:36 AM, Tudor Girba < > tudor@ > > wrote: >> Hi Eliot, >> >> I agree with most things you say (except the conclusion :)), and I think >> that we are talking about complementary issues. >> >> As I mentioned before, there already is a need to distinguish between a >> plain selector and one that is associated with pragmas. This is what you >> find in PragmaType in Spotter and Inspector. This is a kind of >> meta-object and having it adds value. I can search for pragmas âtypeâ (we >> can also call it a PragmaSelector), and I can distinguish between all >> occurrences of a pragma âtypeâ and its utilization in computation. But, >> the current implementation of PragmaType is a mere pseudo-meta-object, >> given that it has no casual connection to the runtime. >> >> What we know from Smalltalk is that the analysis model does not have to >> differ from the runtime one. The consequence is that every time we do see >> a difference, we should investigate because we might uncover a hidden >> need opportunity. >> >> I know the VW model, and indeed, we could have something like: >> >> MyConcept class>>myPragmaDefinition >> âa comment about the pragma" >> > <pragma: #selector> >> >> However, this only deals with the definition of the pragma type not with >> the internal representation. There could still well be an object that >> encapsulates both the selector and the comment. And that object would >> also allow us to build tools around it. We could call it a PragmaType, >> PragmaDefinition, or even PragmaSelector. And we could get the Pragma to >> point to this type either through an inst var or through a query (I would >> probably prefer an instvar). >> >> Well, there already /is/ a meta-object called Pragma, and it gets >> instantiated when one accesses the compiled method via pragmas: >> >> (CompiledMethod allInstances detect: [:m| m pragmas size > 1]) pragmas >> collect: [:ea| {ea. ea class}] {{ > <export: true> > . Pragma} . { > <var: #tablePtr type: 'int *'> > . Pragma}} > > Yes I know :). An instance of Pragma denotes an concrete annotation of a > method. I now would like a meta-object that describes all Pragma instances > having the same selector. For example, the protocol on the class side of > the Pragma class is actually a query protocol that is better suited for > the instance side of a PragmaDescription meta-object. For example: > > Pragma class>>allNamed: aSymbol in: aClass > > would become > > PragmaDescription>>pragmasIn: aClass > > and you would use it like: > > (PragmaDescription named: aSymbol) pragmasIn: aClass I am concerned with this proposal. Effectively, it says only one person/package can ever define a pragma selector. It would interfere with two completely independent developers from using <pragma: #foo> for their own work. I think it would be better to expand on <pragma:...> to be able to declare the symbol, the Pragma class, the comment, etc. which would create the meta instance you desire, but without closing off independent work. The the expression /PragmaDescription for: #foo/ would answer a collection of PragmaDescriptions (0 or more). Other methods in the API could be used to answer the one and only or throw an error if not exactly one, and so on. [I know of no way that the individual description could find /just/ its corresponding <foo> uses. Conversely, I know of no way that the compiler could reliably determine that a method with <foo> was referring to the pragma from one declaration versus another. But, I think that is less a problem than forcing a "Highlander" implementation.] > Creating an instance of PragmaDescription would imply searching the image > for the > <pragma:> > definition. I would also like to have a Flyweight pool per environment > such that we always get only one instance of a PragmaDefinition per > selector (like it happens with Symbols). > > >> So we could add the information you want to Pragma, and have it be lazy. > > It does not quite belong to the Pragma. A comment is common to all Pragma > instances, and having it duplicated at the instance level is less elegant. > > But, looking for the users (all senders of the pragma selector - the > methods that use the annotation) of a Pragma would be even less > inconvenient to have on the instance side of Pragma. > > >> The Pragma could go search for the defining class-side pragma methods and >> use the parser to extract the comment(s) when asked. Hence simple access >> to pragmas, interested only in the selectors for applying, wouldn't have >> their performance be impacted. > > The design sketched above would require no runtime penalty for a Pragma > instance. All code that works now would work identically afterwards. We > would only have one selector in Pragma to get the corresponding > description: > > Pragma>>description > ^ PragmaDescription named: self selector > > Alternatively, we could modify the compilation to associate the > PragmaDescription in an inst var of a Pragma instance. So, > CompiledMethod>>pragmas would always return instances of Pragmas with a > PragmaDefinition inst var. > > I think I would start with the lazy lookup first, and this would disturb > nothing from the current behavior. > > >> I think that this proposition does not remove from the simplicity of the >> implementation at all, but allows the new needs to be accommodated >> nicely. The alternative is to not do anything, in which case we will >> continue to have an analysis-only-pseudo-meta-object which is not nice at >> all. I do not think we should jump on this lightly, but I do think we >> should have a critical look and evaluate the options. >> >> This pseudo-meta-object (Pragma) can sty ill be causally connected, in >> the same way that a MethodReference can be causally connected. The >> causation is things like "remove", "recompile", but that's dubious. It's >> essentially a read-only relationship; one wants to be able to locate the >> method from the pragma, but changing the method from the pragma isn't >> necessarily a good idea. Would you agree that convenience methods like >> "remove" on MethodReference are a bad idea and one should stick to the >> removeSelector: protocol on Behavior and ClassDescription? >> >> >> What do you think? >> >> Have I and enough coffee to scramble my thoughts might be a more >> pertinent question ;-) > > :) > > Cheers, > Doru > > >> >> Cheers, >> Doru >> >> >> > On Jun 27, 2016, at 2:39 PM, Eliot Miranda < > eliot.miranda@ > > wrote: >> > >> > Hi Doru, >> > >> >> On Jun 27, 2016, at 3:52 AM, Tudor Girba < > tudor@ > > wrote: >> >> >> >> Hi, >> >> >> >> The CompiledMethod already has a way to retrieve Pragma instances: >> >> >> >> CompiledMethod>>pragmas. >> >> >> >> However, the Pragma instance does not have a meta-object associated >> with it. So, I would first start from adding that one and linking such a >> PragmaType to its instances. The important thing here would be that all >> Pragma instances with a certain selector should reference the same >> PragmaType. >> > >> > Let me express a dissenting opinion. Our pragma system is minimal yet >> powerful. By using Message instances (with literal arguments) to >> represent pragmas we get >> > - executable pragmas that can be applied using perform: or wrappers >> such as sentTo: >> > - we can use conventional browsing queries (implementors and senders) >> to discover which methods are marked by a specific pragma and what >> pragma-processing tools implement a specific pragma. >> > - a rich pragma language that can have many, named parameters >> > - a system which doesn't need its own language, but reuses the existing >> Smalltalk parsing facilities, and so is easier to learn and to implement >> > >> > So its parsimony is an important part of its virtues. It is minimal. >> > >> > One thing missing from the Squeak/Pharo implementation is the set of >> legal pragmas a class accepts. In VisualWorks a class implements the > <pragma: #pragma:selector:> > (it might be > <pragmas: #(pragma:selector:one: pragma:selector:two:)> > ) to define the legal set of pragmas. [Implementation note, these are > /not/ searched for ahead of compilation; instead, the parser delays > searching for class-side methods containing pragma: pragmas until it > encounters a pragma, and it searches for all class side methods, including > in superclasses). >> > >> > This scheme allows pragmas to be checked; only pragmas in the set of >> allowed pragmas are accepted, and it allows collision-free extensibility; >> any package can add a set of legal pragmas to a class merely by choosing >> a method selector that won't collide with any other containing pragma: >> pragmas, eg >> > kernelPragmas >> > > <pragma: #primitive:> >> > > <pragma: #primitive:error:> >> > > <pragma: #primitive:module:> >> > > <pragma: #primitive:module:error:> >> > >> > We're missing this, which means our compilers don't safely check for >> valid pragmas and can't reject invalid or unrecognized ones, which is >> error prone. >> > >> > If we implemented this then we would have a natural place to comment >> pragmas in the method that defines a particular pragma, one that would be >> found using senders. >> > >> > None of this requires a meta object. It is perfectly recursive; using >> itself to implement itself. I find this very elegant (I didn't invent >> pragma: pragmas; Steve Dahl did, and it's a cool idea). >> > >> > So as an inventor of pragmas I'd like to ask for the minimal >> implementation outlined above. I'd like that we didn't j tricycle a >> specific meta object, with all the additional tools that implies, and >> instead stick to the minimalist and parsimony of the original design and >> use pragmas to comment pragmas. >> > >> >> Cheers, >> >> Doru >> > >> > Thanks for reading. >> > Cheers, Eliot >> > >> >>> On Jun 27, 2016, at 12:34 PM, Denis Kudriashov < > dionisiydk@ > > wrote: >> >>> >> >>> >> >>> 2016-06-27 12:12 GMT+02:00 Tudor Girba < > tudor@ > >: >> >>> Hi, >> >>> >> >>> That is my proposal as well: introduce a first class entity that >> describes a Pragma instance. Who would be interested to play with this? >> >>> >> >>> How it could be done? >> >>> Probably compiler could search preferred Pragma class for given >> selector. And then we will have collection of real pragma instances >> inside CompiledMethod. What do you think? >> >> >> >> -- >> >> www.tudorgirba.com >> >> www.feenk.com >> >> >> >> "Be rather willing to give than demanding to get." >> >> >> >> >> >> >> >> >> >> >> > >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "When people care, great things can happen." >> >> >> >> >> >> >> >> >> -- >> _,,,^..^,,,_ >> best, Eliot > > -- > www.tudorgirba.com > www.feenk.com > > "Not knowing how to do something is not an argument for how it cannot be > done." -- View this message in context: http://forum.world.st/Having-comments-for-pragma-tp4902987p4905621.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

July 8, 2016

Sound on Debian

by jannik laval

Hi pharoers, I just tried sounds on phratch on Debian 8. It returns this message: sound_Start(default) soundStart: snd_add_pcm_handler: Fonction non implantÃ©e Is it a problem known ? Here is my configuration: Image ----- /usr/lib/Phratch/shared/Pharo4.0.image Pharo4.0 Latest update: #40626 Unnamed Virtual Machine --------------- /usr/lib/Phratch/bin/pharo NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 https://github.com/pharo-project/pharo-vm.git Commit: ed4a4f59208968a21d82fd2406f75c2c4de558b2 Date: 2014-05-15 18:23:04 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14826 Unix built on May 15 2014 18:29:39 Compiler: 4.6.3 VMMaker versionString https://github.com/pharo-project/pharo-vm.git Commit: ed4a4f59208968a21d82fd2406f75c2c4de558b2 Date: 2014-05-15 18:23:04 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14826 NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 May 15 2014 Cheers, -- ~~Jannik Laval~~ Enseignant-chercheur Responsable PÃ©dagogique Licence Coordonnateur de Projet en SystÃ¨me d'Information IUT LumiÃ¨re, UniversitÃ© Lyon LumiÃ¨re laboratoire DISP http://www.jannik-laval.eu http://www.phratch.com http://www.approchealpes.info

July 8, 2016

Re: [Pharo-dev] AthensCairoSurface not getting garbage collected

by J.F. Rick

I don't have enough evidence either way, but the signs point to no since the applications that crash are not ones that use form-based paints. I assume they wouldn't be affected by the flush. We did have one crash on a form-based one where it crashed after running for 10 hours. My guess is that one ran out of memory. That crash is probably resolved. But, I'll keep everybody informed as I work more on it. Cheers, Jeff On Thu, Jul 7, 2016 at 3:28 AM Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Jeff, does this flush reduces the amount of crash you are experiencing? > > Alexandre > > > On Jul 6, 2016, at 9:01 PM, J.F. Rick <self(a)je77.com> wrote: > > > > Nicolai, > > > > THANKS! That worked. I no longer have any AthensCairoCanvas hanging > around after executing "CairoBackendCache flush". > > > > Cheers, > > > > Jeff > > > > On Sun, Jul 3, 2016 at 11:58 AM Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > > Hi Jeff, > > > > if you use forms to paint on an AthensCairoCanvas, they are cached in > the CairoBackendCache, > > can you try to flush that cache whith > > CairoBackendCache flush. > > > > > > 2016-06-18 18:36 GMT+02:00 J.F. Rick <self(a)je77.com>: > > I'm using Athens rendering for my multi-touch applications on Pharo5. As > part of that, I create a surface: > > surface := AthensCairoSurface extent: bounds extent asIntegerPoint. > > > > Though the object creating that surface is deleted, the surface sticks > around. So, each time I run the app, I get another instance of > AthensCairoSurface hanging around. That means all the forms stick around as > well. So my image can quickly grow towards the 1GB size. > > > > Is there anything I can do about that? Can I manually get the surface > to delete itself? > > > > Cheers, > > > > Jeff > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

July 8, 2016

[Holidays] 14 days no updates: 14th to end of July

by Marcus Denker

Hi, We just saw that everyone who can press the button for a final integration will be on Holidays from July 14 to the end of the month. This means there will be no update, but the issue tracker will stay open of course, so issues can be submitted, fixed and reviewedâ¦ they will just not end up the downloadable image for that 2 weeks. Marcus

July 8, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] ec7b0e: 60137

by stepharo

>>> Do you think professional developers who use Pharo all day like crashes or hangs ? We are all the same here, we want a stable system. >>> >>> It is not certain that the catalog download is the problem. >>> >>> This specific feature that you think should only be enabled by those who want it (you call them pros) is exactly a beginner's feature: a way to discover every external library written. How ironic that you don't care. >> Sven the students we have are not looking for published packages and if they need, they can use the catalog: entering XML and pressing ok >> there is simple enough. It is not a complex ui. Spotter is a lot more confusing than the catalog UI. But dogma says the inverse so I will stop >> arguing. > Well, you won, the feature is gone. No it is not gone. Update your preferences and help fixing the real problem and we will put it back. You see I produce Spotter videos for the mooc. Do you think that I should have spent all this energy for something that I do not like. Now we should be able to critic features. Stef >>> Yes, newcomers hit all kinds of issues that more experienced users subconsciously avoid, being mindful for that is important. I think we all try to do that, by fixing things, not by turning things off. >>> >>> We lack a proper process to decide these kinds of conflicts. >>> >>>> On 08 Jul 2016, at 11:21, stepharo <stepharo(a)free.fr> wrote: >>>> >>>> Again again and again: How many times do you see students having Pharo frozen because the internet connection in the classroom is fleaky. >>>> >>>> Apparently turning off these people is not an issue to you. Perfect but it is one for me. >>>> >>>> For your productivity boost why can't you click on one setting and put it on? >>>> >>>> Tell me I do not understand. In my dev image I have several settings set for my own usage. >>>> >>>> So why you cannot have one extra one? Especially since preferences are loaded automatically. >>>> >>>> >>>> Then when we will find a way to address the real problem we can just turn the setting on. >>>> >>>> I will have spent half of my life showing software to newbies and may I ask you when is the last time >>>> >>>> you show Pharo to a guy that is learning programming? I do that often (may be too often) >>>> >>>> and in bad situation like in Afrika but not only. >>>> >>>> Stef >>>> >>>> >>>> >>>> Le 6/7/16 Ã 20:19, Sven Van Caekenberghe a Ã©crit : >>>>> I'll try once more to explain. >>>>> >>>>> You like the catalog, don't you ? It was your idea in the first place. With this feature you can just type XML, CSV, JSON or whatever and it will suggest a couple of catalog projects that you can install with just one click, no need to open any tool you don't even know. This is especially good for new people. IT IS A FANTASTIC FEATURE, IT IS THE WAY THINGS SHOULD WORK. It leverages all the work put in the catalog. >>>>> >>>>> Is Spotter or any other part of Pharo perfect ? No. >>>>> >>>>> For many people, Spotter make a huge functional difference, we use it every minute. If it would hang or block the image even once a day, any of us would complain loudly. >>>>> >>>>> Conclusion: it works for 99% of the people/cases. >>>>> >>>>> Even in the 1% where there is a problem, it is not 100% sure it is related to the catalog searching. In the last concrete issue reported, the guy tried disabling the catalog searching AND IT MADE NO DIFFERENCE ! >>>>> >>>>> So again, why turn it off ? It is an overreaction, not engineering. >>>>> >>>>> The underlying problem is that in some very rare, hard to reproduce cases we cannot reliably detect that there is no network. That's about it. >>>>> >>>>> Note also that almost every application or app today will do some network calls, this is how the world work - we should be able to do the same with Pharo, not run away and kill every feature that does a network call. >>>>> >>>>>> On 06 Jul 2016, at 18:14, stepharo <stepharo(a)free.fr> wrote: >>>>>> >>>>>> Who vote to put it in? >>>>>> >>>>>> Seriously I think that my main concern is about getting Pharo stable in any occasion and not giving >>>>>> >>>>>> a bad impression of the system. I takes enough time to build traction and such glitches can spoil >>>>>> >>>>>> our effort in no time. "Yes Pharo froze." >>>>>> >>>>>> So it would be nice to care take of such aspect. >>>>>> >>>>>> I do not understand why super users do not manage to put a reference to on in the preferences. >>>>>> >>>>>> Sorry esteban but I do not buy your argument that something off is remove. No it is off. >>>>>> >>>>>> Stef >>>>>>>> On 06 Jul 2016, at 09:52, GitHub <noreply(a)github.com> wrote: >>>>>>>> >>>>>>>> 18674 Turn spotter catalog off by default >>>>>>>> https://pharo.fogbugz.com/f/cases/18674 >>>>>>> We did not agree on this, at all, there was no public discussion, no vote. >>>>>>> >>>>>>> >>> >> > >

July 8, 2016