[Pharo-project] On the frontpage of news.ycombinator.com
http://news.ycombinator.com/ Sunday morning... but nevertheless :-) Marcus -- Marcus Denker -- http://marcusdenker.de
[Pharo-project] pharo-2.0-tests » 32,mac - Build # 193 - Still Failing!
BUILD FAILUREBuild URLhttps://ci.lille.inria.fr/pharo/job/pharo-2.0-tests/./Architecture=32,OS=mac/193/Project:Architecture=32,OS=macDate of build:Sun, 08 Jul 2012 08:39:05 +0200Build duration:42 secCHANGESNo ChangesCONSOLE OUTPUT[...truncated 665 lines...] OrderedCollection>>do: [sourceFiles do: [:reference | self installSourceFile: reference]] in BasicCodeLoader>>installSourceFiles BlockClosure>>ensure: BasicCodeLoader>>installSourceFiles BasicCodeLoader>>activate BasicCodeLoader class(CommandLineHandler class)>>activateWith: DefaultCommandLineHandler>>handleSubcommand DefaultCommandLineHandler>>handleArgument: DefaultCommandLineHandler>>activate [self new activate] in DefaultCommandLineHandler class>>startUp: BlockClosure>>cull: [each cull: resuming] in [:each | self logStartUpErrorDuring: [each cull: resuming] into: errors tryDebugger: self isInteractive] in SmalltalkImage>>executeDeferredStartupActions: BlockClosure>>on:do: SmalltalkImage>>logStartUpErrorDuring:into:tryDebugger: [:each | self logStartUpErrorDuring: [each cull: resuming] into: errors tryDebugger: self isInteractive] in SmalltalkImage>>executeDeferredStartupActions: OrderedCollection>>do: SmalltalkImage>>executeDeferredStartupActions: SmalltalkImage>>startupImage:snapshotWorked: SmalltalkImage>>snapshot:andQuit: [Smalltalk snapshot: true andQuit: true] in WorldState class>>saveAndQuit BlockClosure>>ensure: CursorWithMask(Cursor)>>showWhile: WorldState class>>saveAndQuit [| selArgCount | (selArgCount := selector numArgs) = 0 ifTrue: [target perform: selector] ifFalse: [selArgCount = arguments size ifTrue: [target perform: selector withArguments: arguments] ifFalse: [target perform: selector withArguments: (arguments copyWith: evt)]]. self changed] in ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: BlockClosure>>ensure: CursorWithMask(Cursor)>>showWhile: ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: ToggleMenuItemMorph(MenuItemMorph)>>mouseUp: ToggleMenuItemMorph(MenuItemMorph)>>handleMouseUp: MouseButtonEvent>>sentTo: ToggleMenuItemMorph(Morph)>>handleEvent: MorphicEventDispatcher>>dispatchDefault:with: MorphicEventDispatcher>>dispatchEvent:with: ToggleMenuItemMorph(Morph)>>processEvent:using: MorphicEventDispatcher>>dispatchDefault:with: MorphicEventDispatcher>>dispatchEvent:with: MenuMorph(Morph)>>processEvent:using: MenuMorph(Morph)>>processEvent: MenuMorph>>handleFocusEvent: [ActiveHand := self. ActiveEvent := anEvent. result := focusHolder handleFocusEvent: (anEvent transformedBy: (focusHolder transformedFrom: self))] in HandMorph>>sendFocusEvent:to:clear: [aBlock value] in PasteUpMorph>>becomeActiveDuring: BlockClosure>>on:do: PasteUpMorph>>becomeActiveDuring: HandMorph>>sendFocusEvent:to:clear: HandMorph>>sendEvent:focus:clear: HandMorph>>sendMouseEvent: HandMorph>>handleEvent: HandMorph>>processEvents [:h | ActiveHand := h. h processEvents. ActiveHand := nil] in WorldState>>doOneCycleNowFor: Array(SequenceableCollection)>>do: WorldState>>handsDo: WorldState>>doOneCycleNowFor: WorldState>>doOneCycleFor: PasteUpMorph>>doOneCycle [[World doOneCycle. Processor yield. false] whileFalse. nil] in MorphicUIManager>>spawnNewProcess [self value. Processor terminateActive] in BlockClosure>>newProcess ---THERE_BE_DRAGONS_HERE Got startup errors: ---THERE_BE_DRAGONS_HERE FileExists: Path / 'Users' / 'hudson' / 'jenkins' / 'workspace' / 'pharo-2.0-tests' / 'Architecture' / '32' / 'OS' / 'mac' / 'Pharo-2.0-AfterRunningTests' / 'package-cache' --- Build step 'Execute shell' marked build as failureRecording test resultsJDK installation skipped: Unknown CPU name: mac os xJDK installation skipped: Unknown CPU name: mac os xDescription set: Email was triggered for: FailureSending email for trigger: Failure
Re: [Pharo-project] StartupPreferences
On Sun, Jul 8, 2012 at 6:17 AM, Sean P. DeNigris s...@clipperadams.comwrote: Mariano, Can any of the script lookup logic from 2.0 be ported to 1.4? Migrate everything (the new logic and all the last improvements) is too much. Mostly because I don't have time and because it is not a dead or alive bug. In fact, it was never before and people never complained ;) What you COULD do if you want is to just do this: StartupPreferences doesn't seem very useful if only the image folder is checked, Why it only searches in the image folder? buildActionList First, we look at image folder, then we look at preferences folder, and finally at general preferences folder ^ OrderedCollection new add: [ self lookInImageDirectory ]; add: [self lookInPreferencesFolder ]; add: [self lookInGeneralPreferencesFolder ]; yourself. it should check there (the version that is in 1.4). The only reason this version would stop searching in other places is if it did find something. When it finds something, it stops searching (in 2.0 it contiues and executes all the ones that are found). given that the initial use case was for working in many fresh images. +99 - S -- View this message in context: http://forum.world.st/StartupPreferences-tp4639058.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. -- Mariano http://marianopeck.wordpress.com
[Pharo-project] [update 2.0] #20194
20194 - Issue 6304: [BUG]: Completion DNU in Inspector/Object Explorer for 2.0 http://code.google.com/p/pharo/issues/detail?id=6304 Issue 6301: Halts in image http://code.google.com/p/pharo/issues/detail?id=6301 Issue 6274: another step to remove StringHolder hierarchy element http://code.google.com/p/pharo/issues/detail?id=6274 -- Marcus Denker -- http://marcusdenker.de
Re: [Pharo-project] On the frontpage of news.ycombinator.com
Super! I just voted it up. On 08 Jul 2012, at 08:23, Marcus Denker wrote: http://news.ycombinator.com/ Sunday morning... but nevertheless :-) Marcus -- Marcus Denker -- http://marcusdenker.de
Re: [Pharo-project] On the frontpage of news.ycombinator.com
I tried, but it wouldn't let me log in, and I couldn't see any way of fixing that. Maybe I'll have better luck from a real computer later. -- Cheers, Peter. On 8 jul 2012, at 12:12, Sven Van Caekenberghe s...@beta9.be wrote: Super! I just voted it up. On 08 Jul 2012, at 08:23, Marcus Denker wrote: http://news.ycombinator.com/ Sunday morning... but nevertheless :-) Marcus -- Marcus Denker -- http://marcusdenker.de
Re: [Pharo-project] StartupPreferences
On Sun, Jul 8, 2012 at 10:16 AM, Mariano Martinez Peck marianop...@gmail.com wrote: On Sun, Jul 8, 2012 at 6:17 AM, Sean P. DeNigris s...@clipperadams.comwrote: Mariano, Can any of the script lookup logic from 2.0 be ported to 1.4? Migrate everything (the new logic and all the last improvements) is too much. Mostly because I don't have time and because it is not a dead or alive bug. In fact, it was never before and people never complained ;) What you COULD do if you want is to just do this: StartupPreferences doesn't seem very useful if only the image folder is checked, Why it only searches in the image folder? buildActionList First, we look at image folder, then we look at preferences folder, and finally at general preferences folder ^ OrderedCollection new add: [ self lookInImageDirectory ]; add: [self lookInPreferencesFolder ]; add: [self lookInGeneralPreferencesFolder ]; yourself. Ok, I was checking an old version of 1.4. Now I see: buildActionList First, we look at image folder, then we look at preferences folder, and finally at general preferences folder self flag: #todo. I'm disabling this sequence because lookup of preferences folder is broken in windows. ^ OrderedCollection new add: [ self lookInImageDirectory ]; add: [self lookInPreferencesFolder ]; add: [self lookInGeneralPreferencesFolder ]; yourself. somigrate all the new version is costly. I don't have time to do it. If you want, you can just enable back for all but for windows: buildActionList First, we look at image folder, then we look at preferences folder, and finally at general preferences folder | directories | self flag: #todo. I'm disabling this sequence because lookup of preferences folder is broken in windows. NOTE: this has been fixed in Pharo 2.0 directories := OrderedCollection new. directories add: [ self lookInImageDirectory ]. (OSPlatform current platformFamily = #Windows) ifFalse: [ directories add: [self lookInPreferencesFolder ]. directories add: [self lookInGeneralPreferencesFolder ]. ]. ^ directories it should check there (the version that is in 1.4). The only reason this version would stop searching in other places is if it did find something. When it finds something, it stops searching (in 2.0 it contiues and executes all the ones that are found). given that the initial use case was for working in many fresh images. +99 - S -- View this message in context: http://forum.world.st/StartupPreferences-tp4639058.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. -- Mariano http://marianopeck.wordpress.com -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-project] [ANN]: Vim Shortcuts for Nautilus (Proof-of-concept)
If I were you, I would have put all the VIM shortcut in one class, instead of putting them around but :) For the attachment, the solution could be to attach simultaneously several shortcuts category. Like that, you could add yours in a specific context, and remove them. An ugly solution right now could be to duplicate all the NautilusSourceCodeShortcuts entries, and to switch between NautilusSourceCodeShortcuts and VIMShortcuts. A kind of hack could be: AbstractNautilusUI classbuildInsertModeKeymappingsOn: aBuilder keymap (KMRepository default categoryForName: #NautilusSourceCodeShortcuts) keymaps do: [:km | (aBuilder shortcut: (km name, 'VIM') asSymbol) category: VimInsertModeShortcuts default: km shortcut do: km action ]. (aBuilder shortcut: #commandMode) category: #NautilusSourceCodeShortcuts #VimInsertModeShortcuts default: Character escape asShortcut do: [ :target | Editor dumbbellCursor: true. target sourceTextArea changed. target sourceTextArea attachKeymapCategory: #VimCommandModeShortcuts ]. It's kind of a hack, but like that you ensure to have the same shortcuts in the midtime Ben On Jul 8, 2012, at 3:13 AM, Sean P. DeNigris wrote: Sean P. DeNigris wrote - how do I remove an individual shortcut or shortcut category from a morph? (so I can toggle the command/insert mode shortcuts) I'm having trouble toggling insert mode... Right now I have AbstractNautilusUI classbuildInsertModeKeymappingsOn: aBuilder keymap (aBuilder shortcut: #commandMode) category: #NautilusSourceCodeShortcuts #VimInsertModeShortcuts default: Character escape asShortcut do: [ :target | Editor dumbbellCursor: true. target sourceTextArea changed. target sourceTextArea attachKeymapCategory: #VimCommandModeShortcuts ]. The problem is that: * I think I have to put these shortcuts into #NautilusSourceCodeShortcuts to have them load without overriding anything * If I don't put them in their own category (i.e. #VimInsertModeShortcuts), I don't know how to remove them when entering command mode (I only see a way to remove whole categories) Guille, Ben - are those assumptions correct and how should I proceed? Thanks, Sean -- View this message in context: http://forum.world.st/ANN-Vim-Shortcuts-for-Nautilus-Proof-of-concept-tp4638987p4639034.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
[Pharo-project] [update 2.0] #20195
20195 - Issue 6259: DataStream is still there http://code.google.com/p/pharo/issues/detail?id=6259 Issue 4095: Suggestion: rename some methods for consistency (just example methods, no API changes) http://code.google.com/p/pharo/issues/detail?id=4095 -- Marcus Denker -- http://marcusdenker.de
Re: [Pharo-project] [ANN]: Vim Shortcuts for Nautilus (Proof-of-concept)
Benjamin Van Ryseghem-2 wrote If I were you, I would have put all the VIM shortcut in one class, instead of putting them around but :) I'll keep that in mind once I get it working ;-) Benjamin Van Ryseghem-2 wrote Like that, you could add yours in a specific context, and remove them. Any luck finding those detach* methods? Googling/Nabbling detachKeymapCategory turned up nothing. Also, I think of my use case here for the enter command mode shortcut as Change the default shortcuts for a Morph class. It seems that what's required for this type of use is a registration mechanism more like the world menu. For the world menu, I can insert an entry at any level, not just an existing one, without overriding anything. In KM currently, in order to do this, it seems we're forced to hitch a ride on an existing category. Maybe a special pragma indicating that certain categories should be attached for the class by default. In summary, I'm still unclear on the relationship between the class-side keymap defaults methods and changing shortcuts on the fly, but what seems to be missing are: * a way to register shortcuts/categories to be attached to a Morph class by default * a way to detach categories * a way to detach individual shortcuts Thanks, this is very exciting. We're *so* close to having this work... Sean -- View this message in context: http://forum.world.st/ANN-Vim-Shortcuts-for-Nautilus-Proof-of-concept-tp4638987p4639088.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
[Pharo-project] pharo-2.0-tests » 32,mac - Build # 194 - Still Failing!
BUILD FAILUREBuild URLhttps://ci.lille.inria.fr/pharo/job/pharo-2.0-tests/./Architecture=32,OS=mac/194/Project:Architecture=32,OS=macDate of build:Sun, 08 Jul 2012 14:57:24 +0200Build duration:37 secCHANGESNo ChangesCONSOLE OUTPUT[...truncated 665 lines...] OrderedCollection>>do: [sourceFiles do: [:reference | self installSourceFile: reference]] in BasicCodeLoader>>installSourceFiles BlockClosure>>ensure: BasicCodeLoader>>installSourceFiles BasicCodeLoader>>activate BasicCodeLoader class(CommandLineHandler class)>>activateWith: DefaultCommandLineHandler>>handleSubcommand DefaultCommandLineHandler>>handleArgument: DefaultCommandLineHandler>>activate [self new activate] in DefaultCommandLineHandler class>>startUp: BlockClosure>>cull: [each cull: resuming] in [:each | self logStartUpErrorDuring: [each cull: resuming] into: errors tryDebugger: self isInteractive] in SmalltalkImage>>executeDeferredStartupActions: BlockClosure>>on:do: SmalltalkImage>>logStartUpErrorDuring:into:tryDebugger: [:each | self logStartUpErrorDuring: [each cull: resuming] into: errors tryDebugger: self isInteractive] in SmalltalkImage>>executeDeferredStartupActions: OrderedCollection>>do: SmalltalkImage>>executeDeferredStartupActions: SmalltalkImage>>startupImage:snapshotWorked: SmalltalkImage>>snapshot:andQuit: [Smalltalk snapshot: true andQuit: true] in WorldState class>>saveAndQuit BlockClosure>>ensure: CursorWithMask(Cursor)>>showWhile: WorldState class>>saveAndQuit [| selArgCount | (selArgCount := selector numArgs) = 0 ifTrue: [target perform: selector] ifFalse: [selArgCount = arguments size ifTrue: [target perform: selector withArguments: arguments] ifFalse: [target perform: selector withArguments: (arguments copyWith: evt)]]. self changed] in ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: BlockClosure>>ensure: CursorWithMask(Cursor)>>showWhile: ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: ToggleMenuItemMorph(MenuItemMorph)>>mouseUp: ToggleMenuItemMorph(MenuItemMorph)>>handleMouseUp: MouseButtonEvent>>sentTo: ToggleMenuItemMorph(Morph)>>handleEvent: MorphicEventDispatcher>>dispatchDefault:with: MorphicEventDispatcher>>dispatchEvent:with: ToggleMenuItemMorph(Morph)>>processEvent:using: MorphicEventDispatcher>>dispatchDefault:with: MorphicEventDispatcher>>dispatchEvent:with: MenuMorph(Morph)>>processEvent:using: MenuMorph(Morph)>>processEvent: MenuMorph>>handleFocusEvent: [ActiveHand := self. ActiveEvent := anEvent. result := focusHolder handleFocusEvent: (anEvent transformedBy: (focusHolder transformedFrom: self))] in HandMorph>>sendFocusEvent:to:clear: [aBlock value] in PasteUpMorph>>becomeActiveDuring: BlockClosure>>on:do: PasteUpMorph>>becomeActiveDuring: HandMorph>>sendFocusEvent:to:clear: HandMorph>>sendEvent:focus:clear: HandMorph>>sendMouseEvent: HandMorph>>handleEvent: HandMorph>>processEvents [:h | ActiveHand := h. h processEvents. ActiveHand := nil] in WorldState>>doOneCycleNowFor: Array(SequenceableCollection)>>do: WorldState>>handsDo: WorldState>>doOneCycleNowFor: WorldState>>doOneCycleFor: PasteUpMorph>>doOneCycle [[World doOneCycle. Processor yield. false] whileFalse. nil] in MorphicUIManager>>spawnNewProcess [self value. Processor terminateActive] in BlockClosure>>newProcess ---THERE_BE_DRAGONS_HERE Got startup errors: ---THERE_BE_DRAGONS_HERE FileExists: Path / 'Users' / 'hudson' / 'jenkins' / 'workspace' / 'pharo-2.0-tests' / 'Architecture' / '32' / 'OS' / 'mac' / 'Pharo-2.0-AfterRunningTests' / 'package-cache' --- Build step 'Execute shell' marked build as failureRecording test resultsJDK installation skipped: Unknown CPU name: mac os xJDK installation skipped: Unknown CPU name: mac os xDescription set: Email was triggered for: FailureSending email for trigger: Failure
Re: [Pharo-project] [ANN]: Vim Shortcuts for Nautilus (Proof-of-concept)
Here is the detach methods filed out. Morph-*NautilusCommon-KeyMappingExtensions.st Description: Binary data KMDispatcher-*NautilusCommon-KeyMappingExtensions.st Description: Binary data They are still extensions here, but they should be moved directly into KM We will succeed :P Ben On Jul 8, 2012, at 2:52 PM, Sean P. DeNigris wrote: Benjamin Van Ryseghem-2 wrote If I were you, I would have put all the VIM shortcut in one class, instead of putting them around but :) I'll keep that in mind once I get it working ;-) Benjamin Van Ryseghem-2 wrote Like that, you could add yours in a specific context, and remove them. Any luck finding those detach* methods? Googling/Nabbling detachKeymapCategory turned up nothing. Also, I think of my use case here for the enter command mode shortcut as Change the default shortcuts for a Morph class. It seems that what's required for this type of use is a registration mechanism more like the world menu. For the world menu, I can insert an entry at any level, not just an existing one, without overriding anything. In KM currently, in order to do this, it seems we're forced to hitch a ride on an existing category. Maybe a special pragma indicating that certain categories should be attached for the class by default. In summary, I'm still unclear on the relationship between the class-side keymap defaults methods and changing shortcuts on the fly, but what seems to be missing are: * a way to register shortcuts/categories to be attached to a Morph class by default * a way to detach categories * a way to detach individual shortcuts Thanks, this is very exciting. We're *so* close to having this work... Sean -- View this message in context: http://forum.world.st/ANN-Vim-Shortcuts-for-Nautilus-Proof-of-concept-tp4638987p4639088.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
[Pharo-project] [update 2.0] #20196
20196 - Issue 6316: Restore display when launching transcripter via menu http://code.google.com/p/pharo/issues/detail?id=6316 Issue 6307: UI inform dialog should use our growl stuff http://code.google.com/p/pharo/issues/detail?id=6307 Issue 6293: Fix FIleSystemTest #testReferenceTo http://code.google.com/p/pharo/issues/detail?id=6293 -- Marcus Denker -- http://marcusdenker.de
[Pharo-project] View from an outsider [was Re: Pharo and Namespaces]
On Jun 27, 2012; 4:27pm, Stephane Ducasse wrote: On Jun 27, 2012, at 4:44 PM, James Foster wrote: Stef, I'm sorry to hear about your burnout and I understand that you are not prepared to seriously discuss the issues that others have raised. I hope when the issue is raised again (it does seem to come up every year or so!) we can correct some of the misunderstandings that exist. yes we are discussing regularly that topic and Camille is writing a master where all the points are discussed and summarized with pros and cons. Now for 20 we should finish all the open tracks we have. Stef Hi, A comment from a complete outsider: I've been following pharo on the side for the last year or so and am very impressed by both smalltalk as a language and pharo as an implementation. I am not trying to even voice an opinion of what's right to focus on for pharo project since that's not my place having nothing invested in it (so far, gearing up to add some pharo parts to my world). It did strike me that it could be interesting to hear the view from an outsider on what would draw interest and more users/developers to the project. Be it inspiration for pharo 2.1 or 3.0 or 4.0 :) I'll first state a belief: I believe that the explosive growth of ruby and python communities to some extent depended on good package management systems making it very easy for people to publish/share/collaborate on packages. A killer app to kick it off, but one needs easy collaboration to grow. On the back of that I'm very excited to see the following pharo efforts being close to coming together into something great: 1. Stripped down core kernel and bootstrap project 2. Fuel for fast serialization and deserialization (can be used for binary packages) 3. FileTree 4. Metacello scripting API 5. Metacella Git/Github integration 6. Tools such as Versionner on top of Metacello for ease of use 7. Namespaces/Environments In terms of getting a lot of people much more comfortable diving into the image world I think that list have great promise. If one can easily start with a minimal kernel, have some simple tooling such that one from e.g. the commandline can bootstrap it via Metacello configurations that pulls in both the parts of the base system one needs and project/application dependencies to get a working image for both development and deployment (via metacello groups for example) it has 2 benefits: 1. Reproducible process which means automation and testing a lot easier for projects (jenkins etc for applications), as well as deployment 2. It's a workflow that's quite similar to how one would for example work with ruby, rubygems and bundler (on a high level). Familiarity draws in more people - it shouldn't be at the cost of a good system, but if one can get both it's a definite positive. Once project/appliation bootstrapped like that and one is working in the image tools like Versionner and Metacello with git/github intregration will provide an excellent workflow for collaboration (push/pull/merge/branch/etc). Again I see 2 benefits: 1. Functionally solid (see e.g. the Practical Git for Smalltalk presentation by Dale) 2. It's familiar to outsiders and has a good chance of attracting new people. Even if one has great in image tooling it's very good to be able to be a lazy follower of a package/project via e.g. github (RSS feeds for changes, nice diffs accessible from any web browser, pull requests, graphical representation of branches etc etc). I for example would be much more likely to have learnt more on pharo implementation if I could have followed it on github for the last year. When collaboration increases and people share a lot of packages via e.g. git github one tend to see exponential reuse and number of new packages created (on the back of what exists), and at least the ruby experience is the average number of package dependencies for a project increases. It's in that point of view I'm seeing namespaces/environments as an important addition. Prefixing names is doable and at a non-human level you can accomplish most of the same things, but on a human level I see it as important - and it gets more important the more collaboration and reuse of existing packages one accomplishes. A non-technical consideration is that developers these days kind of expects some form of namespacing to exist and not seeing it available is something to deter some possible adopters (rightly or wrongly, many times they wouldn't need namespaces/environments, but many may not reflect too deeply on that). I know I twigged at first seeing prefixing being used instead of some form of namespaces. From that this perspective (namespaces/environments more important as more people are, reuse and collaboration happens) it seems quite sensible to put it after the other things on the todo list (as long as it doesn't goes away completely). Hopefully that's of some interest :) I'll continue my journey towards using pharo more - we shall see how it works out for
