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

Re: [Pharo-dev] WhatsUp from: 2015-08-17 until: 2015-08-31

by Dimitris Chloupis

On Thu, Aug 20, 2015 at 4:42 AM Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > 2) Gave a deep reading on Pharo auto completion. > > Auto-completion in Pharo is really bad. It would be fantastic to improve > it. > > Yes indeed, my effort for now is focused in documenting it. I cannot improve what I dont understand. Then will see if I can improve it, by making it more customizable or making it a bit smarter. > > 3) Study how Playgrounds draws its GUI to improve it by making far more > flexible. > > Can you say more about this? > I have talked about this long time ago. I was imagining a new tool I called "Cyclops". The idea of Cyclops was born when I was reading the GTPlayground comment that says "Playground is the correspondent of a classic Smalltalk Workspace. *The problem with the name Workspace is that it implies that work should be carried out in this space, while this is not a best practice*. Playground describes better the intention of providing a place in which we can quickly play with some code." My first reply to this comment was "Why not ?". So the idea is to have a new Workspace that allows the user to create code , add it to a class, inspect, debug , print and do all code tasks without ever leaving the boundaries of the tool. GTPlayground already does this in some way by implementing the inspector inside workspace that also has some browsing capabilities. I would also like to integrate the GTSpotter gui inside GTPlayground. The idea here is to bring all these tools inside a single window. It will be a slow process , for now documenting GTPlayground is the goal, next will be to provide a cleaner design for printing values, creating blocks of code that the GTPlayground is aware of and allows the user to be added to a new or existing class as methods and some code browsing abilities. I am also interested into browsing documentation inside workspace and I have many other ideas. For now the goal is just to read the code of GTPlayground GUI and try to document it One step at a time ;) Cheers, > Alexandre > > > > 4) Study a new programming language Nim , for making dynamic libraries > for pharo , replacing C/C++. Possible scenario of porting SqueakNim to > Pharo. > > > > To Do > > > > 1) Improve my blue theme (Nireas) > > 2) Create an API for Blender for Pharo > > 3) Create my own custom Playground which will be more powerful > > 4) Integrate Nim with Pharo > > > > On Tue, Aug 18, 2015 at 6:23 PM Sean P. DeNigris <sean(a)clipperadams.com> > wrote: > > ### Here's what I've been up to since the last WhatsUp: > > - Ported Moose issue tracker to GitHub > > - GT extension for presentations semi-auto-generated from Magritte > > descriptions > > - data, label, etc pre-filled by default > > - Magritte actions appear as e.g. presentation list selection context > menu > > - Magritte > > - extension for above > > - many little fixes and enhancements > > - [WIP]: Created Glamour browsers from presentations > > - Glamour/GT patches > > - GSoC Mentoring for sQuick Smalltalk project > > > > ### What's next, until 2015-08-31 (*): > > - Camp Smalltalk Portland! > > > > > > > > > > ----- > > Cheers, > > Sean > > -- > > View this message in context: > http://forum.world.st/WhatsUp-from-2015-08-17-until-2015-08-31-tp4843391p48… > > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

Aug. 20, 2015

Re: [Pharo-dev] WhatsUp from: 2015-08-17 until: 2015-08-31

by Alexandre Bergel

Just wondering, you need to have libssh2 working in order to get libgit2? How far are we from getting this working? Cheers, Alexandre > On Aug 19, 2015, at 3:22 AM, Max Leske <maxleske(a)gmail.com> wrote: > > - libgit2 and libssh2 now compile and link nicely on the Windows, Linux and Mac VMs > - upgraded libgit2 to version 0.23 > - Linux build for libgit2 is now green. Windows build exhibits some very strange problems with unzipping, will fix that later. > - Discovered a possible bug in libssh2 on Linux which prevents libgit2 from working with ssh -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 20, 2015

Re: [Pharo-dev] WhatsUp from: 2015-08-17 until: 2015-08-31

by Alexandre Bergel

> 2) Gave a deep reading on Pharo auto completion. Auto-completion in Pharo is really bad. It would be fantastic to improve it. > 3) Study how Playgrounds draws its GUI to improve it by making far more flexible. Can you say more about this? Cheers, Alexandre > 4) Study a new programming language Nim , for making dynamic libraries for pharo , replacing C/C++. Possible scenario of porting SqueakNim to Pharo. > > To Do > > 1) Improve my blue theme (Nireas) > 2) Create an API for Blender for Pharo > 3) Create my own custom Playground which will be more powerful > 4) Integrate Nim with Pharo > > On Tue, Aug 18, 2015 at 6:23 PM Sean P. DeNigris <sean(a)clipperadams.com> wrote: > ### Here's what I've been up to since the last WhatsUp: > - Ported Moose issue tracker to GitHub > - GT extension for presentations semi-auto-generated from Magritte > descriptions > - data, label, etc pre-filled by default > - Magritte actions appear as e.g. presentation list selection context menu > - Magritte > - extension for above > - many little fixes and enhancements > - [WIP]: Created Glamour browsers from presentations > - Glamour/GT patches > - GSoC Mentoring for sQuick Smalltalk project > > ### What's next, until 2015-08-31 (*): > - Camp Smalltalk Portland! > > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/WhatsUp-from-2015-08-17-until-2015-08-31-tp4843391p48… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 20, 2015

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

by Alexandre Bergel

But do we really go into the VM to understand whatâs going on? Alexandre > On Aug 19, 2015, at 7: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@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@iam.unibe.ch] De la part deAlexandre 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 >> > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 20, 2015

[pharo-project/pharo-core]

by GitHub

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

Aug. 19, 2015

[pharo-project/pharo-core] 3d7f1f: 50248

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 3d7f1f3ac45310096f565c2d11014df16889ad57 https://github.com/pharo-project/pharo-core/commit/3d7f1f3ac45310096f565c2d… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-08-20 (Thu, 20 Aug 2015) Changed paths: M Kernel.package/Rectangle.class/instance/rectangle functions/intersect_ifNone_.st R Komitter.package/BigCogInitialState.class/README.md R Komitter.package/BigCogInitialState.class/class/private/imageData.st R Komitter.package/BigCogInitialState.class/class/private/size.st R Komitter.package/BigCogInitialState.class/definition.st R Komitter.package/BigCogInitialState.class/instance/protocol/nextState.st R Komitter.package/BigCogInitialState.class/instance/protocol/stepTime.st R Komitter.package/BigCogState2.class/README.md R Komitter.package/BigCogState2.class/class/private/imageData.st R Komitter.package/BigCogState2.class/class/private/size.st R Komitter.package/BigCogState2.class/definition.st R Komitter.package/BigCogState2.class/instance/protocol/nextState.st R Komitter.package/BigCogState2.class/instance/protocol/stepTime.st R Komitter.package/BigCogState3.class/README.md R Komitter.package/BigCogState3.class/class/private/imageData.st R Komitter.package/BigCogState3.class/class/private/size.st R Komitter.package/BigCogState3.class/definition.st R Komitter.package/BigCogState3.class/instance/protocol/nextState.st R Komitter.package/BigCogState3.class/instance/protocol/stepTime.st M Komitter.package/KomitterUI.class/instance/initialization/initializeWidgets.st M Komitter.package/KomitterUI.class/instance/initialization/populateTreeFor_.st R Komitter.package/TreeWithLoading.class/README.md R Komitter.package/TreeWithLoading.class/class/specs/defaultSpec.st R Komitter.package/TreeWithLoading.class/definition.st R Komitter.package/TreeWithLoading.class/instance/accessing/loadingAnimation.st R Komitter.package/TreeWithLoading.class/instance/accessing/tree.st R Komitter.package/TreeWithLoading.class/instance/api/loading.st R Komitter.package/TreeWithLoading.class/instance/api/loading_.st R Komitter.package/TreeWithLoading.class/instance/initialization/initialize.st R Komitter.package/TreeWithLoading.class/instance/initialization/initializeWidgets.st R Komitter.package/TreeWithLoading.class/instance/private/loadingSpec.st R Komitter.package/TreeWithLoading.class/instance/private/showLoading.st R Komitter.package/TreeWithLoading.class/instance/private/showTree.st R Komitter.package/TreeWithLoading.class/instance/private/treeSpec.st R Komitter.package/TreeWithLoading.class/instance/reflective operations/doesNotUnderstand_.st M Manifest-Core.package/TheManifestBuilder.class/instance/private/packageNameOf_.st M MonticelloGUI.package/MCWorkingCopyBrowser.class/instance/morphic ui/defaultExtent.st M Nautilus.package/Nautilus.class/class/accessing/parentOfClass_.st M Refactoring-Critics.package/RBRefersToClassRule.class/instance/running/checkClass_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50247.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50248.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50247.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50248.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M System-Support.package/extension/TBehavior/instance/allCallsOn.st Log Message: ----------- 50248 14789 Nautilus can not browse anonymous classes https://pharo.fogbugz.com/f/cases/14789 16302 Move variable assignment outside of blocks and Rewrite ifTrue:ifFalse: using min:/max: in Rectangle>>#intersect:ifNone: https://pharo.fogbugz.com/f/cases/16302 16261 Monticello window is ridiculously small when opened from the world menu https://pharo.fogbugz.com/f/cases/16261 16291 Remove scary weel of the Komitter https://pharo.fogbugz.com/f/cases/16291 http://files.pharo.org/image/50/50248.zip

Aug. 19, 2015

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

by Vincent BLONDEAU

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@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 <mailto:vincent.blondeau@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@iam.unibe.ch> [mailto:moose-dev-bounces@iam.unibe.ch <mailto:moose-dev-bounces@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 <mailto:kurs@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 <mailto:alexandre.bergel@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 <mailto:Moose-dev@iam.unibe.ch> https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Aug. 19, 2015

Re: [Pharo-dev] Nautilus questions

by Dimitris Chloupis

On Wed, Aug 19, 2015 at 5:51 PM Sean P. DeNigris <sean(a)clipperadams.com> wrote: > kilon.alios wrote > > > For example, let's say your project has a class that implements a > generically-named method, like #asMorph. If you try to rename that method > via Refactoring, Pharo will try to rename all #asMorph methods, and update > all senders, in the entire system, not just yours. But if you scope the > browser first to your package or class, you can restrict the environment to > which the refactoring is applied This sounds useful indeed. Is just the browser aware of the scope or is also the pharo environment aware of the scope too ? It would be nice if the scope could expand to include multiple packages , or is this something left to groups ?

Aug. 19, 2015

Re: [Pharo-dev] Nautilus questions

by Stephan Eggermont

On 19-08-15 11:20, Peter UhnÃ¡k wrote: > This sounds like a neat idea (although I don't know if Moprhic > understands "hold button for X time"). Take a look at how MouseClickState is used in HandMorph>>waitForClicksOrDrag: aMorph event: evt selectors: clickAndDragSelectors threshold: threshold Stephan

Aug. 19, 2015

Re: [Pharo-dev] Nautilus questions

by Stephan Eggermont

On 19-08-15 14:58, Ben Coman wrote: > One thing that sometimes annoys me with current Nautilus, is that to > view a class definition, I need to deselect the method and loose my > context there. Tabs seem a great way to be able to flick back and forth > without loosing context. Nice example. That is functionality that could be well delivered by having a hover popup over the class name showing the class definition. Stephan

Aug. 19, 2015