- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Tiling Window Manager in 3.0: working but still issues with WorldMorph

by Sean P. DeNigris

philippeback wrote > There is the World management icon which is still there and it looks like > it can create worlds but switching between them just breaks havoc. Can you clarify "havoc" a bit? I just get a PasteUpMorph DNU related to the addition of WorldMorph. Changing PasteUpMorph -> WorldMorph fixes that and I'm able to create an addition world. When changing between, there is something wrong with display updating. If I "restore display" after switching, it seems to work normally. No more time right now, I'll take another look asap... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Tiling-Window-Manager-in-3-0-working-but-still-issues… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

March 10, 2014

Re: [Pharo-dev] TWM and 3.0: icons/themes, UpdatingMenuMorph

by Sean P. DeNigris

philippeback wrote > I am trying to get TWM to work in 3.0 > ... > Now, things do load but there is the deprecation warnings about the way > icons are handled. FYI, checking the repo, I notice I had already fixed the icon stuff in TWM-GUI-SeanDeNigris.12, but you seem to have based your work on TWM-GUI-SeanDeNigris.9, and TWM-GUI-PhilippeBack.14 depends on TWM-GUI-PhilippeBack.(10 to: 13) which are not in the stub repo. ----- Cheers, Sean -- View this message in context: http://forum.world.st/TWM-and-3-0-icons-themes-UpdatingMenuMorph-tp4747979p… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

March 10, 2014

Re: [Pharo-dev] Pharo3.0 and Halos: very annoying to work with

by Sean P. DeNigris

philippeback wrote > Now, we get the new menu when doing the special clicking (e.g. > Shift-Alt-Click in Windows, Cmd-Shift Click in OSX). On what are you clicking when the menu appears? Halos in 30792 on Mac works fine for me cycling in both directions when I click on several different Nautilus panes. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo3-0-and-Halos-very-annoying-to-work-with-tp47482… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

March 10, 2014

Re: [Pharo-dev] Tiling Window Manager in 3.0: working but still issues with WorldMorph

by Sean P. DeNigris

philippeback wrote > There is the World management icon which is still there and it looks like > it can create worlds but switching between them just breaks havoc. > > Maybe should we just remove that feature from TWM as 3.0 doesn't seem to > be > multiworld friendly. Thanks for getting it running! Give me a few days to look into it before we consider removing. I find the feature immensely valuable. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Tiling-Window-Manager-in-3-0-working-but-still-issues… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

March 10, 2014

Re: [Pharo-dev] About inspectors

by Alexandre Bergel

Wow!!!!! Screenshots are (too) small? Hey people! Use the like button and enter a comment :-) We should be able to do the same thing for DBPedia. Alexandre On Mar 9, 2014, at 7:06 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Thanks for the interest. > > I added now a new blog post in which I detail an investigation scenario of a Postgres DB with the GTInspector: > http://www.humane-assessment.com/blog/dynamic-exploration-of-a-postgres-db-… > > The post includes a video that kind of gets you through the most important parts: > - use the playground > - query the DB and preview the results through dedicated presentations > - navigate through objects and code to learn the API > - build a visualization in place and continue exploration > - extend the inspector with a dedicated presentation > > Please let me know what you think. > > Cheers, > Doru > > > > On Sat, Mar 8, 2014 at 8:48 AM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > Doru, > > Where to look on your blog for a view on the essentials of this? I see http://www.humane-assessment.com/blog/making-the-pharo-settings-browser-ope… for example. A video? > > I look at the blog and vids but it is a bit hard to find a basic demo to grasp things. > > TIA > Phil > > > On Sat, Mar 8, 2014 at 8:16 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > I hope not. What are we trying to optimize? > > If you look closely at the GT work, you might notice that it is not just a tool, it's a whole new philosophy for coding. The EyeInspector picked only one aspect out of a whole. > > One high goal is to change programming such that the inspector + debugger to capture most of the coding experience. This is what live means. Right now, in the default Pharo we only code small things in the debugger and nothing in the inspector. We work on the idea of a moldable IDE that will change all that. > > Let's look at some facts. Right now, in my image I have 75 different extensions for GTInspector. And the total amount of lines of code has barely passed 1000 LOC (including all utility code). These are not just independent views, but they are combinable. The amount of use cases supported span a wide range: querying source code, visualizing performance, navigating file system, querying DB, and more (read the posts from humane-assessment.com for hints in this direction). > > We programmed most of these extensions from within the inspector both because it's fun and because it's significantly more productive. And I am not the only one. This power is not serendipity, it's by design. And we only started to untap this potential. > > There is still a long way for the concept of inspector and I believe there is a large payoff in it, too. > > Optimizing for a small thing now should not be the way to go :) > > Cheers, > Doru > > > > > On Fri, Mar 7, 2014 at 11:23 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Well I would hope that some kind of convergence would be possible in the future. Maybe some kind of abstract meta description like magritte, that different tools can use. > > On 07 Mar 2014, at 16:43, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > > Hi everyone. > > > > This day Iâve attended Moose dojo and Iâm pretty impressed with the possibilities of GTInspector. The one thing that Iâve noticed is that both GTInspactor and EyeInspector support custom inspections for objects. Iâm wandering if we can come up with a common protocol to give an object specific infector view, and not develop a separate thing for each inspector. > > > > Uko > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 10, 2014

Re: [Pharo-dev] About inspectors

by Tudor Girba

Thanks, Alex. I showed the above demo to non-Smalltalk developers with the idea of positioning Pharo/Moose as a one-stop-tool-for-all-sorts-of-analyses (I also showed them file manipulation). By the look in their eyes (they know the real pain of having poor and incomplete tools), I am pretty convinced that this is a significant opportunity that Pharo should take. Doru On Sat, Mar 8, 2014 at 1:13 PM, Alexandre Bergel <alexandre.bergel(a)me.com>wrote: > Indeed having particular views is only one (minor) aspect. The coding and > navigation flow GTTools offers is fantastic. > I am not a big fan of Glamour scripting language, but what is built on top > of it is remarkable. It may even be a killing app for Pharo. > > Alexandre > > Le 08-03-2014 Ã 4:16, Tudor Girba <tudor(a)tudorgirba.com> a Ã©crit : > > I hope not. What are we trying to optimize? > > If you look closely at the GT work, you might notice that it is not just a > tool, it's a whole new philosophy for coding. The EyeInspector picked only > one aspect out of a whole. > > One high goal is to change programming such that the inspector + debugger > to capture most of the coding experience. This is what live means. Right > now, in the default Pharo we only code small things in the debugger and > nothing in the inspector. We work on the idea of a moldable IDE that will > change all that. > > Let's look at some facts. Right now, in my image I have 75 different > extensions for GTInspector. And the total amount of lines of code has > barely passed 1000 LOC (including all utility code). These are not just > independent views, but they are combinable. The amount of use cases > supported span a wide range: querying source code, visualizing performance, > navigating file system, querying DB, and more (read the posts from > humane-assessment.com for hints in this direction). > > We programmed most of these extensions from within the inspector both > because it's fun and because it's significantly more productive. And I am > not the only one. This power is not serendipity, it's by design. And we > only started to untap this potential. > > There is still a long way for the concept of inspector and I believe there > is a large payoff in it, too. > > Optimizing for a small thing now should not be the way to go :) > > Cheers, > Doru > > > > > On Fri, Mar 7, 2014 at 11:23 PM, Sven Van Caekenberghe <sven(a)stfx.eu>wrote: > >> Well I would hope that some kind of convergence would be possible in the >> future. Maybe some kind of abstract meta description like magritte, that >> different tools can use. >> >> On 07 Mar 2014, at 16:43, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >> > Hi everyone. >> > >> > This day I've attended Moose dojo and I'm pretty impressed with the >> possibilities of GTInspector. The one thing that I've noticed is that both >> GTInspactor and EyeInspector support custom inspections for objects. I'm >> wandering if we can come up with a common protocol to give an object >> specific infector view, and not develop a separate thing for each inspector. >> > >> > Uko >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > -- www.tudorgirba.com "Every thing has its own flow"

March 9, 2014

Re: [Pharo-dev] About inspectors

by Tudor Girba

Thanks for the interest. I added now a new blog post in which I detail an investigation scenario of a Postgres DB with the GTInspector: http://www.humane-assessment.com/blog/dynamic-exploration-of-a-postgres-db-… The post includes a video that kind of gets you through the most important parts: - use the playground - query the DB and preview the results through dedicated presentations - navigate through objects and code to learn the API - build a visualization in place and continue exploration - extend the inspector with a dedicated presentation Please let me know what you think. Cheers, Doru On Sat, Mar 8, 2014 at 8:48 AM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > Doru, > > Where to look on your blog for a view on the essentials of this? I see > http://www.humane-assessment.com/blog/making-the-pharo-settings-browser-ope… example. A video? > > I look at the blog and vids but it is a bit hard to find a basic demo to > grasp things. > > TIA > Phil > > > On Sat, Mar 8, 2014 at 8:16 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> I hope not. What are we trying to optimize? >> >> If you look closely at the GT work, you might notice that it is not just >> a tool, it's a whole new philosophy for coding. The EyeInspector picked >> only one aspect out of a whole. >> >> One high goal is to change programming such that the inspector + debugger >> to capture most of the coding experience. This is what live means. Right >> now, in the default Pharo we only code small things in the debugger and >> nothing in the inspector. We work on the idea of a moldable IDE that will >> change all that. >> >> Let's look at some facts. Right now, in my image I have 75 different >> extensions for GTInspector. And the total amount of lines of code has >> barely passed 1000 LOC (including all utility code). These are not just >> independent views, but they are combinable. The amount of use cases >> supported span a wide range: querying source code, visualizing performance, >> navigating file system, querying DB, and more (read the posts from >> humane-assessment.com for hints in this direction). >> >> We programmed most of these extensions from within the inspector both >> because it's fun and because it's significantly more productive. And I am >> not the only one. This power is not serendipity, it's by design. And we >> only started to untap this potential. >> >> There is still a long way for the concept of inspector and I believe >> there is a large payoff in it, too. >> >> Optimizing for a small thing now should not be the way to go :) >> >> Cheers, >> Doru >> >> >> >> >> On Fri, Mar 7, 2014 at 11:23 PM, Sven Van Caekenberghe <sven(a)stfx.eu>wrote: >> >>> Well I would hope that some kind of convergence would be possible in the >>> future. Maybe some kind of abstract meta description like magritte, that >>> different tools can use. >>> >>> On 07 Mar 2014, at 16:43, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >>> >>> > Hi everyone. >>> > >>> > This day I've attended Moose dojo and I'm pretty impressed with the >>> possibilities of GTInspector. The one thing that I've noticed is that both >>> GTInspactor and EyeInspector support custom inspections for objects. I'm >>> wandering if we can come up with a common protocol to give an object >>> specific infector view, and not develop a separate thing for each inspector. >>> > >>> > Uko >>> >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > -- www.tudorgirba.com "Every thing has its own flow"

March 9, 2014

Crashing the vm in a reproducible way

by Pharo4Stef

Hi We already experienced this with Pavel in December. Once I loaded UnReloader from SystemConfigurations from STHUB/Pharo and I run unload I crash systematically the latest vm obtain with wget -O - http://get.pharo.org/30+vmLatest | bash the method crashing the system is checkState "self new checkState" | difference | difference := SystemNavigation default allUnimplementedCalls copyWithoutAll: unimplementedCalls. difference ifNotEmpty: [ self log nextPutAll: 'new unimplemented calls: '; cr; nextPutAll: difference asString; cr.]. difference := (SystemNavigation default obsoleteClasses collect: #name) asSet copyWithoutAll: obsoleteClasses. difference ifNotEmpty: [ self log nextPutAll: 'new obsoleteClasses:'; cr; nextPutAll: difference asString; cr]. difference := (Undeclared collect: #name) asSet copyWithoutAll: undeclared. difference ifNotEmpty: [ self log nextPutAll: 'new undeclared: '; cr; nextPutAll: difference asString; cr]. unimplementedCalls := SystemNavigation default allUnimplementedCalls. obsoleteClasses := (SystemNavigation default obsoleteClasses collect: #name) asSet. undeclared := (Undeclared collect: #name) asSet. Now executing the expressions one by one once the tools have been removed does not crash. Stef

March 9, 2014

Re: [Pharo-dev] Is there some shared memory space?

by Max Leske

Solve. Neither image nor VM nor Fuel luckily :) Cheers, Max On 08.03.2014, at 23:15, Max Leske <maxleske(a)gmail.com> wrote: > > On 08.03.2014, at 23:12, btc(a)openInWorld.com wrote: > >> Max Leske wrote: >>> >>> >>> On 08.03.2014, at 15:03, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >>> >>>> Hmm, as far as I know there is no "shared memory space"... or bah.. what do you mean by that? >>>> >>>> From my understanding I'd say that when you do: >>>> >>>> "- I fix the bug (i.e., commenting the self error)" >>>> >>>> you introduce some side effect that causes an infinite recursion => lots of contexts are reified because the vm stack gets full => you run out of memory >>> >>> No, it seems that the error lies with Fuel, although I canât yet say why. Iâm still investigating. >>> >>> Max >> >> Max, You've been able to reproduce the problem? > > Not really. Iâm working on it with Roberto and post back once weâve figured out more. Iâm pretty sure though that VM and image are fine (apart from limiting the heap size to 500MB *grml*). > > >> >>> >>>> >>>> BTW, are you on windows, linux, mac? which vm/image? >>>> >>>> Guille >>>> >>>> >>>> On Sat, Mar 8, 2014 at 2:55 PM, roberto.minelli(a)usi.ch <roberto.minelli(a)usi.ch> wrote: >>>> Anyone on this? It is very frustrating for me. >>>> >>>> Cheers, >>>> Roby >>>> >>>> On Mar 7, 2014, at 1:05 PM, roberto.minelli(a)usi.ch wrote: >>>> >>>> > >>>> > On Mar 7, 2014, at 12:24 PM, Max Leske <maxleske(a)gmail.com> wrote: >>>> > >>>> >> >>>> >> On 07.03.2014, at 11:55, roberto.minelli(a)usi.ch wrote: >>>> >> >>>> >>> Hi guys, >>>> >>> >>>> >>> I am experiencing a very strange problem that makes me think there is some shared memory problem with Pharo. >>>> >>> >>>> >>> Here are the steps that lead to the problem: >>>> >>> - I have an image, I do something (i.e., materializing objects with Fuel) >>>> >>> - I encounter a problem and a debugger pops up with a âself error: something" >>>> >>> - I close the debugger >>>> >>> - I close the image >>>> >> >>>> >> Do you save the image? If so, are you saving references to the already materialized objects? >>>> > >>>> > Of course, I did not save the image. Otherwise Iâd have understood the behavior. >>>> > >>>> >> >>>> >>> - I reopen the image >>>> >>> - I fix the bug (i.e., commenting the self error) >>>> >>> - I re-run the same thing as in the first step >>>> >>> - An OutOfMemory error appears. >>>> >>> >>>> >>> Any clue? >>>> >>> >>>> >>> Thanks, >>>> >>> Roberto

March 9, 2014

Re: [Pharo-dev] Windows FileSystem '\test\bar' not an absolute path

by btc＠openinworld.com

Ben Coman wrote: > > I have some strong concerns about the semantics of FileSystem on MS > Windows treating '\directory' as a relative path rather than an > absolute path. > > For example currently... > '/tmp/test.txt' asFileReference fullName --> > 'C:\Users\Ben\AppData\Roaming\Pharo\images\30790\tmp\test.txt' > > when it _should_ go... > '/tmp/test.txt' asFileReference fullName --> 'C:\tmp\x.txt' > > This seems to be by design per '\test\bar' below... > > WindowsStoreTest>>testAbsolutePath > #('c:\' 'C:\temp' 'A:\temp\test') do: [:each | > self assert: (WindowsStore current pathFromString: each) > isAbsolute ] > WindowsStoreTest>>testRelativePath > #('a' 'bin\foo' 'temp\test' '\test\bar') do: [:each | > self assert: (WindowsStore current pathFromString: each) > isRelative ] > > However taking as reference the Windows Command Shell (cmd.exe)... > (1) C:\> mkdir \a\b\a\c > (2) C:\> cd a > (3) C:\a> cd b > (4) C:\a\b> cd \a > (5) C:\a> > > observe that after 'cd \a' (4) the working directory becomes absolute > 'C:\a' rather than relative 'C:\a\b\a' . > > Microsoft defines [1] a file name is RELATIVE to the current directory > if it DOES NOT begin with: > * A single backslash, for example, "\directory" or "\file.txt". This > is also referred to as an ABSOLUTE path. > > Indeed all Windows applications I know operate this way. Using > different semantics is a bug. > > [1] > http://msdn.microsoft.com/en-us/library/aa365247.aspx#fully_qualified_vs._r… > > > What are your thoughts? > cheers -ben > > I propose something like the following changes... WindowsStoreTest>>testAbsolutePath #('c:\' 'C:\temp' 'A:\temp\test' '\test\bar') do: [:each | "<--MODIFIED" self assert: (WindowsStore current pathFromString: each) isAbsolute ] WindowsStoreTest>>testRelativePath #('a' 'bin\foo' 'temp\test' 'C:temp\test' ) do: [:each | "<--MODIFIED" self assert: (WindowsStore current pathFromString: each) isRelative ] Path>>absoluteWindowsPathRegex ^ (absoluteWindowsPathRegex ifNil: [ absoluteWindowsPathRegex := '([a-zA-Z]\:)?\\.*' asRegex ]) copy "<--MODIFIED" " absoluteWindowsPathRegex := '[a-zA-Z]\:\\.*' asRegex ]) copy" "<--PREVIOUS" Path>>first "<--ADDED" ^ self at: 1. WindowsStore>>printPath: aPath on: aStream (aPath first includes: $:) ifFalse: [ aStream nextPutAll: self currentDisk ; nextPut: self delimiter ]. "<--ADDED" aPath printOn: aStream delimiter: self delimiter WindowsStore>>currentDisk "<--ADDED" "Assumes workingDirectory is always an absolute path" ^ disk ifNil: [ disk = FileSystem workingDirectory path first ] after which... '/tmp/test.txt' asFileReference fullName --> 'C:\tmp\test.txt' This needs some polish. I haven't looked for adverse effects yet. However Pathtest, FileReferenceTest, FileSystemTest & WindowsStoreTest are all green. What do your think? cheers -ben

March 9, 2014