August 2015 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50271 Home: https://github.com/pharo-project/pharo-core

Aug. 26, 2015

Re: [Pharo-dev] [Pharo-users] [ann] brick on top of bloc - preview

by Sven Van Caekenberghe

Very nice ! > On 25 Aug 2015, at 22:13, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > We are happy to announce the first preview version of Brick, a new widget set created from scratch on top of Bloc. > > Brick is being developed primarily by Alex Syrel (together with Alain Plantec, Andrei Chis and myself), and the work is sponsored by ESUG. Brick is part of the Glamorous Toolkit effort and will provide the basis for the new versions of the development tools. > > Brick's goal is to provide a beautiful looking widget set, and the default look is based on material design. The widgets are theme-able. > > Right now, there exists: > - Label > - Simple button > - Toggle button > - Checkbox > - Radio button > - Window with or without an active title bar that can include various visual actions and info > - Menu > - Beautiful scrollbars that are thin by default and enlarge when the mouse hovers over it > - Scalable list for huge amounts of items with various heights > (The list also allows one for embedding text widgets with in place editing) > > The next immediate target is the creation of a new Pager widget (the widget that is behind the current GTInspector). > > You can see some screenshots on the official site: > http://gt.moosetechnology.org/brick > > To play with it, you can download a ready-made image: > https://ci.inria.fr/moose/job/gtoolkit5/lastSuccessfulBuild/artifact/gtoolk… > > and, in a Bloc space, you can browse the examples: > BrExampleBrowser exampleOpen > > We would be happy to hear your feedback. > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Aug. 25, 2015

[ann] brick on top of bloc - preview

by Tudor Girba

Hi, We are happy to announce the first preview version of Brick, a new widget set created from scratch on top of Bloc. Brick is being developed primarily by Alex Syrel (together with Alain Plantec, Andrei Chis and myself), and the work is sponsored by ESUG. Brick is part of the Glamorous Toolkit effort and will provide the basis for the new versions of the development tools. Brick's goal is to provide a beautiful looking widget set, and the default look is based on material design. The widgets are theme-able. Right now, there exists: - Label - Simple button - Toggle button - Checkbox - Radio button - Window with or without an active title bar that can include various visual actions and info - Menu - Beautiful scrollbars that are thin by default and enlarge when the mouse hovers over it - Scalable list for huge amounts of items with various heights (The list also allows one for embedding text widgets with in place editing) The next immediate target is the creation of a new Pager widget (the widget that is behind the current GTInspector). You can see some screenshots on the official site: http://gt.moosetechnology.org/brick To play with it, you can download a ready-made image: https://ci.inria.fr/moose/job/gtoolkit5/lastSuccessfulBuild/artifact/gtoolk… and, in a Bloc space, you can browse the examples: BrExampleBrowser exampleOpen We would be happy to hear your feedback. Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

Aug. 25, 2015

Re: [Pharo-dev] [Playground] Getting contents from the cloud?

by Bernardo Ezequiel Contreras

GREAT!!!!! (what a dummy!) thanks. On Tue, Aug 25, 2015 at 3:38 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Paste the link into GTSpotter and press enter :) > > Peter > > On Tue, Aug 25, 2015 at 8:31 PM, Bernardo Ezequiel Contreras < > vonbecmann(a)gmail.com> wrote: > >> Hi all, >> There is a button to publish the contents of the playground to the >> cloud but there isn't a button to get the contents from the cloud? >> Is that on purpose? i don't get it. >> >> >> -- >> Bernardo E.C. >> >> Sent from a cheap desktop computer in South America. >> > > -- Bernardo E.C. Sent from a cheap desktop computer in South America.

Aug. 25, 2015

Re: [Pharo-dev] [Playground] Getting contents from the cloud?

by Peter UhnÃ¡k

Paste the link into GTSpotter and press enter :) Peter On Tue, Aug 25, 2015 at 8:31 PM, Bernardo Ezequiel Contreras < vonbecmann(a)gmail.com> wrote: > Hi all, > There is a button to publish the contents of the playground to the > cloud but there isn't a button to get the contents from the cloud? > Is that on purpose? i don't get it. > > > -- > Bernardo E.C. > > Sent from a cheap desktop computer in South America. >

Aug. 25, 2015

[Playground] Getting contents from the cloud?

by Bernardo Ezequiel Contreras

Hi all, There is a button to publish the contents of the playground to the cloud but there isn't a button to get the contents from the cloud? Is that on purpose? i don't get it. -- Bernardo E.C. Sent from a cheap desktop computer in South America.

Aug. 25, 2015

Re: [Pharo-dev] Strange Validation with issue 15820

by Ben Coman

On Tue, Aug 25, 2015 at 11:30 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi, > > We have an issue that is platform dependent (file-related): > > https://pharo.fogbugz.com/f/cases/15820/Better-File-API > > Now, we tested with Nicolai in Windows, Mac and Linux and we had all tests > green. However, the monkey does not seem to want to be green. > > - Would anyone have an idea of what should be disturbing the monkey? No ideas, except if you can't isolate it, maybe its possible to SSH into the CI server, map VNC ports back to your local machine and debug the image on the CI server. cheers -ben > - Can people in different linuxes/unixes test the slice just to make sure we > are on the right path? (that is, load the slice and run the tests in the > File package). > > Thanks a lot, > Guille

Aug. 25, 2015

Re: [Pharo-dev] [Moose-dev] Re: Object new foo

by Eliot Miranda

Hi Vincent, On Sun, Aug 23, 2015 at 9:53 AM, Vincent BLONDEAU < vincent.blondeau(a)polytech-lille.net> wrote: > Hi Eliot, > > > > Thanks for your help. > > The problem has been resolved! > > In fact a class was removed or renamed in Pharo, and the Moose debugger > calls it just before the opening. > > So it created an infinite loop, because the class wasnât understood by the > system, so it opened another debugger, etcâ¦. > > > > Do you think something can be made to not break the image and so to break > this infinite loop? > It may make sense to set a flag early in Debugger opening, and test this flag immediately before it is set to check for recursion. But the issue is what to do in that case. One can't open a debugger, because the attempt is failing. So one can only fall back on some more primitive error handler. Note that the flag should be specific to the thread of control, which may be difficult if the Debugger runs in a separate process. One doesn't want to prevent multiple debuggers, only stop recursion within a single error. > A solution may to open either another registered debugger, or the > emergency debugger? > Yes, the emergency debugger. > > > I can create an image with the problem if needed. > > > > Vincent > > > > *De :* Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] *De la part > de* Eliot Miranda > *EnvoyÃ© :* jeudi 20 aoÃ»t 2015 22:13 > *Ã :* Pharo Development List > *Cc :* Moose-related development; Squeak Virtual Machine Development > Discussion > *Objet :* Re: [Pharo-dev] [Moose-dev] Re: Object new foo > > > > Hi Vincent, > > > > does the image lock up when you execute Exception signal? The two > functions you see looping are part of the implementation of primitives 195 > & 196, findNextUnwindContextUpTo: (primitiveFindNextUnwindContext) > & terminateTo: (primitiveTerminateTo). So if the image locks up the > question is, is what is creating a circular structure of contexts, the VM > or the image? I am willing to take a look at an image that contains the > case. If you can create an image which enters the lop on start-up without > my having to do anything I'm happy to take a look. > > > > On Wed, Aug 19, 2015 at 3:22 PM, Vincent BLONDEAU < > vincent.blondeau(a)polytech-lille.net> wrote: > > Hi, > > > > On last Moose image, I debugged the VM and executed âException signalâ. > > I paused the VM and saw that 2 methods are looping together in > gcc3x-cointerp.c: > > static sqInt findMethodWithPrimitiveFromContextUpToContext(sqInt > primitive, sqInt senderContext, sqInt homeContext); > > static sqInt findMethodWithPrimitiveFromFPUpToContext(sqInt primitive, > char *startFP, sqInt homeContext); > > > > The image is looping only when the debugger is launch on Error (not by > launching it by the script below). > > > > Maybe someone on the Pharo mailing list knows what is happening? > > > > Thanks in advance, > > > > Cheers, > > Vincent > > > > *De :* moose-dev-bounces(a)iam.unibe.ch [mailto: > moose-dev-bounces(a)iam.unibe.ch] *De la part de* Andrei Chis > *EnvoyÃ© :* mardi 18 aoÃ»t 2015 10:53 > *Ã :* Moose-related development > *Objet :* [Moose-dev] Re: Object new foo > > > > Hi Vincent, > > > > You example will also kill the Pharo debugger :) > > The issue is that you pass 'Processor activeProcess' which gets terminated > when you close the debugger. > > When you open the debugger you need to make sure the process > > on which it is opened is suspended and can get terminated with no problem. > > > > A different way to redo the example would be: > > > > context := Context > > sender: nil > > receiver: {1 . 2 . 2} > > method: (OrderedCollection>>#add:) > > arguments: #(10). > > process := Process > > forContext: context > > priority: Processor userInterruptPriority. > > GTGenericStackDebugger openOn: (DebugSession process: process context: > context). > > > > There is a basic test for opening the debugger > in GTGenericStackDebuggerSmokeTest but more could help. > > > > Cheers, > > Andrei > > > > > > On Mon, Aug 17, 2015 at 11:53 PM, Vincent BLONDEAU < > vincent.blondeau(a)polytech-lille.net> wrote: > > Indeed. Maybe some tests has to be added.. > > > > But for now, it seems that the debugger is crashing the imageâ¦ Not just by > launching it: > > GTGenericStackDebugger openOn: (DebugSession process: Processor > activeProcess context: (Context > > sender: nil > > receiver: {1 . 2 . 2} > > method: (OrderedCollection>>#add: ) > > arguments: #(10))) > > > > But when an exception is thrown, its seems that we fall into an infinite > loop around the primitive 199. Maybe the context is not well set? > > > > Cheers, > > Vincent > > > > > > > > *De :* moose-dev-bounces(a)iam.unibe.ch [mailto: > moose-dev-bounces(a)iam.unibe.ch] *De la part de* Alexandre Bergel > *EnvoyÃ© :* lundi 17 aoÃ»t 2015 13:26 > *Ã :* Moose-related development > *Objet :* [Moose-dev] Re: Object new foo > > > > This is weird that such bug can be introduced and no alarm is raised > > > > Alexandre > > > Le 17 aoÃ»t 2015 Ã 08:03, Jan KurÅ¡ <kurs(a)iam.unibe.ch> a Ã©crit : > > Yep I had this problem (falled back to previous version), I suspected > debugger being the reason. > > Cheers Jan > > > > On Sun, 16 Aug 2015 03:05 Alexandre Bergel <alexandre.bergel(a)me.com> > wrote: > > in Moose 6.0 simply freezes. > Anyone else sees this? > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > > > > > -- > > _,,,^..^,,,_ > > best, Eliot > -- _,,,^..^,,,_ best, Eliot

Aug. 25, 2015

Re: [Pharo-dev] Strange Validation with issue 15820

by Guillermo Polito

Cool, tomorrow I'll sit next to you :). El mar., 25 de ago. de 2015 a la(s) 5:39 p. m., Thomas Heniart < heniart.thomas(a)gmail.com> escribiÃ³: > In Files-Tests 2 failures for me > BinaryFileStreamTest>>#testOpenFile > FileTest>>#testOpeningFileObjectCreatesFile > > Cheers, > Thomas > > 2015-08-25 17:30 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > >> Hi, >> >> We have an issue that is platform dependent (file-related): >> >> https://pharo.fogbugz.com/f/cases/15820/Better-File-API >> >> Now, we tested with Nicolai in Windows, Mac and Linux and we had all >> tests green. However, the monkey does not seem to want to be green. >> >> - Would anyone have an idea of what should be disturbing the monkey? >> - Can people in different linuxes/unixes test the slice just to make sure >> we are on the right path? (that is, load the slice and run the tests in the >> File package). >> >> Thanks a lot, >> Guille >> > >

Aug. 25, 2015

Re: [Pharo-dev] Strange Validation with issue 15820

by Thomas Heniart

In Files-Tests 2 failures for me BinaryFileStreamTest>>#testOpenFile FileTest>>#testOpeningFileObjectCreatesFile Cheers, Thomas 2015-08-25 17:30 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > Hi, > > We have an issue that is platform dependent (file-related): > > https://pharo.fogbugz.com/f/cases/15820/Better-File-API > > Now, we tested with Nicolai in Windows, Mac and Linux and we had all tests > green. However, the monkey does not seem to want to be green. > > - Would anyone have an idea of what should be disturbing the monkey? > - Can people in different linuxes/unixes test the slice just to make sure > we are on the right path? (that is, load the slice and run the tests in the > File package). > > Thanks a lot, > Guille >

Aug. 25, 2015