July 2016 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Issue with Ulysse?

by Yuriy Tymchuk

It was the 1:40:00 timeout, but the report is weird indeed. https://ci.inria.fr/pharo/job/Pharo-6.0-Issue-Validator/6957/console Uko > On 30 Jul 2016, at 20:08, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > Hi! > > It looks like Ulysse is not working properly. Here is the report he/it entered for case 18846 > > https://pharo.fogbugz.com/f/cases/18846 > > Assigned to Everyone by Ulysse The Galactic Monkey From Outer Space 07/29/2016 (Yesterday) 2:23 PM > Status changed from 'Resolved (Monkey is checking)' to 'Work Needed'. > Issue Validation Failed: https://ci.inria.fr/pharo/job/Pharo-6.0-Issue-Validator/6957//artifact/vali… > Errors: 1 | > > I click on the link, > https://ci.inria.fr/pharo/job/Pharo-6.0-Issue-Validator/6957//artifact/vali… > > And it says absolutely nothing. > > So, what should I do to make Ulysse happy? > > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

July 31, 2016

Issue with Ulysse?

by Alexandre Bergel

Hi! It looks like Ulysse is not working properly. Here is the report he/it entered for case 18846 https://pharo.fogbugz.com/f/cases/18846 Assigned to Everyone by Ulysse The Galactic Monkey From Outer Space 07/29/2016 (Yesterday) 2:23 PM Status changed from 'Resolved (Monkey is checking)' to 'Work Needed'. Issue Validation Failed: https://ci.inria.fr/pharo/job/Pharo-6.0-Issue-Validator/6957//artifact/vali… Errors: 1 | I click on the link, https://ci.inria.fr/pharo/job/Pharo-6.0-Issue-Validator/6957//artifact/vali… And it says absolutely nothing. So, what should I do to make Ulysse happy? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

July 30, 2016

magritteXML fixes

by Sean Glazier

Hi, I tried to publish fixes to the Magritte XML package and the Smalltalk hub is not working. I published off to our own repository. I there an ETA on its getting fixed or an alternative repository to publish to? Kind Regards, Sean Glazier

July 30, 2016

Re: [Pharo-users] Programmatic generation of new class

by Tudor Girba

> On Jul 29, 2016, at 8:07 PM, Brad Selfridge <bsselfridge(a)gmail.com> wrote: > > I forgot to mention that I'm working in Pharo 4.0. I changed the "package:" > parameter to "category:" and it worked like a charm. I guess that I need to > move up to Pharo 5.0 pretty soon. Yes, you do :) Doru > > > ----- > Brad Selfridge > -- > View this message in context: http://forum.world.st/Programmatic-generation-of-new-class-tp4908659p490871… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > -- www.tudorgirba.com www.feenk.com "Be rather willing to give than demanding to get."

July 30, 2016

[ANN] Bugfixes for Metacello github .zip issues

by Dale Henrichs

For additional details see the pull request[4]. Bugfixes 1. Issue #405[1] <https://github.com/dalehenrich/metacello-work/issues/405>: Github .zip download not downloaded to |/tmp| as expected ... Pharo-5.0 (& 6.0) 2. Issue #406[2] <https://github.com/dalehenrich/metacello-work/issues/406>: Github .zip download file should be deleted after archive is extracted Update baseline to reference |pharo6.0_dev| branch of Filetree for Pharo6.0[3] <https://github.com/dalehenrich/metacello-work/commit/6b810849235d6ac5e5bd55…> Dale [1] https://github.com/dalehenrich/metacello-work/issues/405 [2] https://github.com/dalehenrich/metacello-work/issues/406 [3] https://github.com/dalehenrich/metacello-work/commit/6b810849235d6ac5e5bd55… [4] https://github.com/dalehenrich/metacello-work/pull/408

July 29, 2016

Re: [Pharo-users] OpenGLES2 binding available!

by Thibault Raffaillac

+1 for your analysis! > One of the biggest issue of OpenGL is related with vsync, which is an operation that can block all of the Pharo processes. It does indeed, but is one way to sync with display rate (until we get threaded FFI of course then a thread can handle the wait). Currently we have to way to know the ideal time to start redraw, so as to minimise the delay between processing an event and displaying its feedback. Standard way is redraw with fixed independent frequency, which incurs an average feedback delay of (display period+redraw period)/2, and a waste of processing time if faster than display rate. VSync in video games has a bad press because people redraw right after it returns: _ Process events _ Draw scene _ Swap buffers <- pauses until scene is displayed _ Loop back That gives a worse feedback delay, but we could to pause a bit before processing stuff: _ Delay(display period - last redraw duration - redraw jitter) _ Process events _ Draw scene _ Swap buffers _ Loop back I find it very hard to find good info on VSync, and low latency event handling on PC in general, so please don't pan this idea too hard, this is just for experiment fun :) > A far worse problem with OpenGL is that the current OpenGL context is a > thread local variable, which do not interact at all with Pharo processes. > This is the reason of why I added the OSWindowRenderThread class for > serializing OSWindow and OpenGL animations. SDL2 renderers are usually > implemented using OpenGL. They are two correct solution for this problem: > - Having a VM that maps each Pharo Process into an operating system thread, > - Not using OpenGL at all. > > The others low level graphics API (Vulkan, Direct 3D and Metal) do not rely > on a global thread local storage variable. These APIs are object oriented, > so handles are passed in each API call. Yes, this is a major flaw in OpenGL. A GL context is global to all Pharo processes, meaning one Process could draw in an other Process area if preempted at the wrong moment. But a simple way to circumvent this is giving all display Processes (using OpenGL) the same priority. > Anyway, implementing a Athens backend from scratch is a really hard problem. Agreed. The difficulty with a hardware backend for Athens is it comes from software world. Some primitives are a nightmare to accelerate, resulting in usually incomplete hardware backends (https://developer.android.com/guide/topics/graphics/hardware-accel.html#uns…) This is annoying for users because some primitives may turn off acceleration entirely, and force you to dig into the internal GL mud. To me the use of hardware drawing is either explicit or none. If appended to Athens it should be very clear what goes to the GPU and what not.

July 29, 2016

Re: [Pharo-users] Programmatic generation of new class

by Brad Selfridge

I forgot to mention that I'm working in Pharo 4.0. I changed the "package:" parameter to "category:" and it worked like a charm. I guess that I need to move up to Pharo 5.0 pretty soon. ----- Brad Selfridge -- View this message in context: http://forum.world.st/Programmatic-generation-of-new-class-tp4908659p490871… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 29, 2016

Re: [Pharo-users] switching to metadata-less gitfiletree

by Peter Uhnak

On Fri, Jul 29, 2016 at 06:58:02PM +0200, Thierry Goubier wrote: > Hi Peter, > > Le 29/07/2016 Ã 18:05, Peter Uhnak a Ã©crit : > > Hi, > > > > I've followed this thread > > http://forum.world.st/How-do-I-convert-a-FileTree-project-to-Metadataless-G… > > to switch to metadata less format, > > > > Specifically: > > > > 1. change `.filetree` file, 2. load the repo to a clean image 3. make > > a change to each package and commit it > > > > This worked correctly, however having to recommit each package is > > annoying if there are several. > > the "resaving" thing isn't necessary. It would have happened anyway on the > next save for a package, and gitfiletree never reads the metadata anyway. > > > My question is: > > > > * is it safe to directly remove the incriminating files (all > > monticello.meta/version & methodProperties.json files), > > Yes. You could also ask git to ignore them (some do that :)). > > > * is it possible to mass-commit all packages with simple script, > > Yes. > > > * or should I just ignore the metadata and eventually someone will > > make a change to the package so the metadata silently disappears? > > You could ignore, yes. > > I'd choose ignoring. Once the property (metadata-less) is set on the > repository, it is kept and maintained. Just don't forget to commit it :) > Yeah, this looks like the best and easiest solution. Thanks! Peter

July 29, 2016

Re: [Pharo-users] Programmatic generation of new class

by ClÃ©ment Bera

On old versions of Pharo you need to use: #subclass:instanceVariableNames:classVariableNames:poolDictionaries:package: That might be it. On Fri, Jul 29, 2016 at 6:14 PM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > Can you show the full trace? Because I am regularly doing something > similar without any problems. > In fact if I copy/paste your code (and just change the classes that I > have) it works fine. > > Btw. did you override such methods in your system? > > Peter > > On Fri, Jul 29, 2016 at 07:05:04AM -0700, Brad Selfridge wrote: > > I'm trying to programmatically generate a new class, but am getting the > > following error: > > > > DynamicDescriptorSystem class(Object)>>doesNotUnderstand: > > #subclass:instanceVariableNames:classVariableNames:package: > > > > This is the method that I'm trying to execute: > > > > buildNewDescriptorSystemUsing: aDescriptorSystemClassName > > > > descriptorSystem := > > DynamicDescriptorSystem subclass: aDescriptorSystemClassName > asSymbol > > instanceVariableNames: '' > > classVariableNames: '' > > package: packageName asString > > > > I see examples of this all over Pharo and I copied this code almost > > verbatim. > > > > What am I doing wrong? > > > > > > > > ----- > > Brad Selfridge > > -- > > View this message in context: > http://forum.world.st/Programmatic-generation-of-new-class-tp4908659.html > > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > > >

July 29, 2016

Re: [Pharo-users] switching to metadata-less gitfiletree

by Thierry Goubier

Hi Peter, Le 29/07/2016 Ã 18:05, Peter Uhnak a Ã©crit : > Hi, > > I've followed this thread > http://forum.world.st/How-do-I-convert-a-FileTree-project-to-Metadataless-G… > to switch to metadata less format, > > Specifically: > > 1. change `.filetree` file, 2. load the repo to a clean image 3. make > a change to each package and commit it > > This worked correctly, however having to recommit each package is > annoying if there are several. the "resaving" thing isn't necessary. It would have happened anyway on the next save for a package, and gitfiletree never reads the metadata anyway. > My question is: > > * is it safe to directly remove the incriminating files (all > monticello.meta/version & methodProperties.json files), Yes. You could also ask git to ignore them (some do that :)). > * is it possible to mass-commit all packages with simple script, Yes. > * or should I just ignore the metadata and eventually someone will > make a change to the package so the metadata silently disappears? You could ignore, yes. I'd choose ignoring. Once the property (metadata-less) is set on the repository, it is kept and maintained. Just don't forget to commit it :) Thierry

July 29, 2016