Re: [Pharo-dev] FogBugsz issue assignment
On Wed, Jan 7, 2015, at 05:50 PM, Marcus Denker wrote: > > > On 06 Jan 2015, at 15:13, MartinW wrote: > > > > Whenever I reply to an issue or resolve an issue, everybody gets > > automatically removed from "assigned to this issue" and I am set as the only > > one the issue is assigned to. > > > > Is this intended? > > > > I just entered a new bug > > (https://pharo.fogbugz.com/f/cases/14679/Fix-layout-glitch-in-FileDialogWindow-s-text-preview), > > then it is assigned to everybody. > > After i resolved it as "fix review needed" it gets automatically only > > assigned to me. But exactly now it should be assigned to everybody, so that > > someone can review it? Or do i misunderstand the mechanism? > > > > For me the whole “to whom the issue is asking to” is confusing, too. > I think that the issue is always assigned back to the “owner” after every > step. > So, the idea here is pretty simple: when you resolve a case, the person who opened the case should be the one to decide whether you *actually* fully handled their issue, because *they're* the one who reported it in the first place. If they agree, they close it. If they don't agree, they reopen it. If you've ever had to deal with a major company's help desk helpfully "resolving" your issue while you can still trivially reproduce it, you'll appreciate why FogBugz works this way by default. But many open source projects don't quite work that way. If Pharo's one of them, just change away from FogBugz' default workflow to one that's more to your choosing. An Administrator just needs to click on Settings -> Workflow, find the relevant workflow, and change what happens to assignment when a case is resolved. You can pick "-- No Change --", or "Everybody", or a specific user, or a virtual user, or whatever you feel is appropriate. You can even vary this by the type of thing getting resolved, so if e.g. you feel that features should resolve to Everybody, but bugs should resolve to the original reporter, you can easily make that distinction. Hope that helps. --Benjamin (Note that, regardless of whether you alter the workflow or not, if you just want to make a comment, you should simply "Edit" the case. This will allow you to leave a note without altering who it's assigned to or its resolution state, which should leave it assigned to "Everybody".)
Re: [Pharo-dev] ZnEasy and post:data:
On Thu, Oct 2, 2014, at 01:28 AM, Sven Van Caekenberghe wrote: > ZnClient is your friend (it is a builder) : > > ZnClient new > url: 'http://some/thing'; > formAt: #foo put: #bar; > formAt: 'baz' put: 'quux'; > post. > Ah, that's indeed perfect. I think I discounted ZnClient initially because I was thinking of it being primarily useful for pipelined operations, but your proposal is *way* cleaner, even if I throw beOneShot in there. Thanks for the pointer. --Benjamin
[Pharo-dev] ZnEasy and post:data:
Hey all,
This is probably me missing something, but: for an upcoming
presentation, I wanted to find the tersest way to demonstrate making an
HTTP POST. Something equivalent to Python's
requests.post('http://some/thing', data={'foo': 'bar', 'baz':
'quux'})
The closest I could come up with for Pharo was
ZnEasy post: 'http://some/thing' data:
(ZnApplicationFormUrlEncodedEntity withAll: {
'foo' -> 'bar'.
'baz' -> 'quux'.
} asDictionary)
I just wanted to verify that is, in fact, the shortest way to do this.
I feel as if I'm almost certainly missing a utility method around the
ZnApplicationFormUrlEncodedEntity bit, and, especially for demos,
terseness matters. (It's obviously trivial to write a utility method if
this *is* the shortest way to do this, but then people in the audience
won't be able to execute the resulting code snippet without the utility
method.)
Thanks,
--Benjamin
[Pharo-dev] Quitting the community
Hello guys, I am sending this email to explain why I am quiting the Pharo community, as well as the Smalltalk community. I can not bear Stephane Ducasse's behavior anymore whether at a public level or a private level. It seems that his ego is preventing him from being able to have a discussion without overreacting, being agressive, or insulting. I can not approve how Stephane is constantly talking behind my back to unleash his irrationnal wrath and to provide his very own version of the facts. I can not see how this can lead to a peaceful and respectful community where we can all have fun building a future. Therefore I will not be part of this project anymore, since the way Stephane is acting is taking away all the fun I can have interacting with all of you. It was a hard decision to take, but I can not be part of a community led by someone whose behaviour is going against all my principles. I wish to all of you to have fun, and keep me in touch if you want to have a beer someday ;) Ben
Re: [Pharo-dev] Adding menu to ListModel
I answered again. Short version: could you report an issue here https://github.com/spec-framework/spec/issues Thanks, Ben On 12 Aug 2014, at 15:14, Yuriy Tymchuk wrote: > So Ben answered my question: http://stackoverflow.com/a/25242253/982238 > > but with his approach I get MenuMorph(Object)>>doesNotUnderstand: #addGroup:. > Any ideas why? > > Uko > > On 11 Aug 2014, at 12:17, Yuriy Tymchuk wrote: > >> Hi guys. >> >> I need a little help with adding a menu to the ListModel (in Spec). Can you >> take a look please: >> http://stackoverflow.com/questions/25240931/add-menu-to-listmodel >> >> Cheers. >> Uko >
Re: [Pharo-dev] New address for the Spec jenkins
You can comment the entry (as well as every one) so we can gather all the idea and have a backlog of the discussion Then the output will be moved into a wiki page Ben On 11 Aug 2014, at 13:00, stepharo wrote: > Roadmap can be discussed here: > https://github.com/spec-framework/spec/issues/16 > > Great > Do you mean that I should edit the file? > > Here is my wishlist > >- check the extensions. I analyzed many Spec extensions and moved the > extensions that were simply missing methods to their >respective packages. But may be I missed some of them. I paid attention to > conserve layers (model not getting in the widgets). > >- I would like that ReactiveVariable get renamed as NewValueHolder > (because we have 15 years of books and concepts that use that name) >It should take you less than 5 min to do it and it would be great that > Spec does not diverge from concepts for the sake of it. > > - to do a pass over the different layers to ensure the separation of > concerns between models <-> adapters <-> widgets >=> i imagine that this point is related to > >Could we remove the interpretation layer between Morphic adapter and > Morphic. From a **Morphic**-adapter point of view I know that I'm talking to > a Morph >because this is my reason d'etre. I can help creating the > delegating methods. > >- to implement a Magritte like meta-description mechanism to build UI > easily >=> I will see if gary can show what he is doing. I hope that he > will attend ESUG. >Because he has all the widgets described with a kind of > metadescription based on that he can build interactively UI >and with some "type information" provide panes to control widgets. >Did you watch the video is colleague from pinesoft sent around? >They could build a new UI in a couple minutes. > >- I do not remember exactly but while I was studying polymorph I saw that > some widgets where only used once by Spec and I would like to see how we can >remove this dependency (may be it was about menu). > > Stef >
Re: [Pharo-dev] New address for the Spec jenkins
Roadmap can be discussed here: https://github.com/spec-framework/spec/issues/16 Ben On 10 Aug 2014, at 20:58, stepharo wrote: > Hi ben > > do you have a roadmap that we can discuss for spec? > Because there are several points I would like to fixed. > > Stef > > On 10/8/14 17:19, Benjamin wrote: >> If people are interested having the latest >> Spec bleeding image, it can now be retrieved at: >> http://benjamin.is-a-geek.com:8080/job/Spec/ :) >> >> >> Ben >> >
[Pharo-dev] New address for the Spec jenkins
If people are interested having the latest Spec bleeding image, it can now be retrieved at: http://benjamin.is-a-geek.com:8080/job/Spec/ :) Ben
Re: [Pharo-dev] About your contributions: Improve Pharo right now, right there.
On Aug 7, 2014, at 9:47 AM, stepharo wrote: >> It’s up to the community to be involved with the tools they love and to >> submit patches, and you’re totally right to remind everyone that it’s up to >> us to improve Pharo if we want to keep it alive, but it’s up to the core >> team to make sure that it’s easy for us to do so, and I think that Pharo’s >> not doing terribly well on that front right now. >> > We add a description on the old web site but he got lost. > Now in a nutshell, to submit a fix > > - donwload latest image (there is a script on download) > - do a fix for a giving bug > - publish a slice press (+ slice) in MC, add the dirty packages > - publish it in the inbox (click on inbox and press save) > - take a fresh image. > - reload it and check that it fixes the problem (open MC and click on > inbox + open). > > Does it help? > Was it so complex? Yep, it helps. The issue isn’t that it was complex; it’s that it was undocumented. The new links are helpful. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Pharo-dev] Browsing Object is slow
Without testing it more, I can’t tell you, but your code seems to make sense :) Ben On 07 Aug 2014, at 13:47, Camille Teruel wrote: > Hi everyone, > > I noticed that browsing Object take several seconds (5s on my machine). > Evaluate Nautilus openOnClass: Object. > After profiling, I found it's because of > ClassWidget>>setCachedHierarchyClass: that calls SortHierarchically > class>>buildHierarchyForClasses: with a big collection of classes. > But the browser opens on the package view by default, not the hierarchy view. > So if I replace: > > ClassWidget>>showHierarchy: anObject > showHierarchy := anObject. > self selectedClass ifNotNil:[: class | > self setCachedHierarchyClass: class] > by: > > ClassWidget>>showHierarchy: aBoolean > (showHierarchy := aBoolean) > ifTrue: [ self selectedClass ifNotNil: [ :class | self > setCachedHierarchyClass: class] ] > > it solves the problem. > But I don't know that part of the system well and I don't know if it's the > correct thing to do or if we should try to improve performances of > SortHierarchically instead. > So tell me what you think about it. > Here is the bug entry: > https://pharo.fogbugz.com/f/cases/13795/Browsing-certain-classes-takes-several-seconds > > > Thanks, > Camille
Re: [Pharo-dev] About your contributions: Improve Pharo right now, right there.
On Aug 4, 2014, at 3:51 PM, stepharo wrote: > Hi guys > > I'm sure that most of you did not realize it, but Pharo does not magically > improve. It improves because some of us are looking > at the tracker issues and looking at the code and improving it. > > Since Pharo is yours I wonder why you do not take the time to improve. In > fact, this is the key advantage of true open-source: being able to have > an impact. An example, I was fed up to have a stupid widget to move method > between protocol and classes between packages. I fixed it. > It took my 20 min without knowing anything about Nautilus. > > And it improved Pharo Right now, Right there. > Of course if more people would be improving Pharo we could also focus on > enabling technology and frameworks. But > apparently we have to choose either we improve Pharo now or we invent cool > stuff that takes time. > I wonder why I do not go for the fame of writing a cool stuff instead of just > improving systematically the system. > > I wrote some roadmaps for people willing also to help. > >https://github.com/pharo-project/pharo-workingRoadmaps > Okay, so that’s good, but you guys really need to improve the documentation on the mechanical walkthrough of how to actually claim and submit a bug fix. Today, I happened to have some spare time, so I figured, what the hell, why not see if I can’t fix some bugs blocking the Pharo 4 release. It’s a reach, granted, but I used to be good at Smalltalk, I’m still a good programmer, and I figure at least one of the blockers is in the really-annoying-but-technically-easy bucket that no one was willing to touch yet, so chances are good. Armed with my old knowledge of how Squeak contrib used to work, I at least got as far as manually downloading a VM, manually downloading a .changes/.image, and manually downloading a .sources. Then I go to pharo.org and… Well, hmm. No instructions on the submission or development process? Well, no matter, I know you guys use FogBugz, so maybe on the FogBugz wiki? The landing page is unhelpful; clicking on the word “here” at “Reporting or Fixing a Bug?” takes me to http://pharo.org/get-involved which is a 404. Heading back, I try “Documentation”, which contains a lot of documentation, but none how to submit fixes. Likewise, I can get great info on the workflow of a bug, but not on how to move code through that workflow. At this point, by luck, I realize that there’s a link to “Contribute” in the TOC in FogBugz. Brilliant, exactly what I want! And it has a video walkthrough, no less, which takes me to http://vimeo.com/75183993 and…nope, that’s a 404 again. Thankfully, the link below it appears to let me download a nice MP4, which does walk me through…submitting a slice. I actually have no idea if this is the right way to do things anymore, but given that you guys seem to have a super-active GitHub repo, I kind of doubt it. And while there’s some documentation scattered around about how to use Git and Pharo, it’s not centralized or obvious. It’s up to the community to be involved with the tools they love and to submit patches, and you’re totally right to remind everyone that it’s up to us to improve Pharo if we want to keep it alive, but it’s up to the core team to make sure that it’s easy for us to do so, and I think that Pharo’s not doing terribly well on that front right now. —Benjamin
Re: [Pharo-dev] Moving to GitHub
I had jenkins job doing that :) But sadly, my server is now sleeping in a box since I moved out :) Ben On 04 Aug 2014, at 11:53, Yuriy Tymchuk wrote: > I’m follower of "new day – new image” way :) > > Uko > > On 04 Aug 2014, at 11:48, kilon alios wrote: > >> Well lately I have been questioning the need for configurations . I am >> considering doing only the second port of your blog post. Ask github for the >> latest release of my project , download it, unzip it and point pharo to the >> unziped directory. Then pharo can periodocally keep probing github to see if >> there is a new release and prompt the user for an update. All that with a >> single click from the user or even automagically. But I have to figure out >> how to do that with Pharo first :) >> >> >> On Mon, Aug 4, 2014 at 12:23 PM, Yuriy Tymchuk wrote: >> You don’t have to. Just keep your configuration (here is a guide how to do >> it >> http://sleepycoders.blogspot.ch/2014/04/how-to-distribute-your-github-pharo.html) >> on some monticello repo, and assemble your image on CI. Yes, if someone >> want’s to modify your project they have to use git, but as far as I know, >> Pharo is slowly moving git way anyway :) >> >> Cheers. >> Uko >> >> On 04 Aug 2014, at 11:17, kilon alios wrote: >> >>> yeah I will also move my latest project to github. I am already more active >>> with github than I am in SThub anyway. The one thing that stopped me so >>> far is that I don't want to force people to install git to get the latest >>> version of my project. SThub is great for this. >>> >>> >>> On Mon, Aug 4, 2014 at 12:03 PM, Yuriy Tymchuk wrote: >>> Well, thankfully I keep all my latest projects on github, and I have >>> configurations of them in the image. But CI is not working and anyway it’s >>> a strange situation. Is there any other service where I can keep my >>> configurations? Because that’s the only thing I version with monticello are >>> configurations as I want to use gofer to load my projects. And here >>> reliability is much more important then other features. >>> >>> Uko >>> >>> >>> On 04 Aug 2014, at 10:59, kilon alios wrote: >>> oh boy thats looks nasty bug, hope its not permanent. On Mon, Aug 4, 2014 at 11:44 AM, Yuriy Tymchuk wrote: Hi, I was on vacation last weak, have I missed anything? Because my SmaltalkHub user does not have any projects http://smalltalkhub.com/#!/~YuriyTymchuk (and I had a bunch of them). Uko >>> >>> >> >> >
Re: [Pharo-dev] Android VM Status
Good job! ;) Ben On 31 Jul 2014, at 16:33, Jean Baptiste Arnaud wrote: > Hi, > I made some advance on Android StackVM (using the standard unix sources). > > :-) > > Last Unix Stack VM with last 40Pharo image (a little bit modified cause au > no-NativeBoost and some constraint from the Android Sandboxing ). > Content: > - Somes lines of code change in SqUnixMain.c (using if define android, but > not a lot, just for allow to load external lib :-). > - 1 communication with java / C files, (will be split in two or three file > one for printing debugging, one or two for core). > - 1 external graphical plugins. vm-display-android, really short but for > android, because the rendering is done by Android. > > > All these plugins are includes (not deeply tested yet, but most of them > should work): > AndroidPlugin (for now I just allow to do debug printing from the image in > the logCat), BitBltPlugin, B2DPlugin, BMPReadWriterPlugin, CroquetPlugin, > DSAPrims, FFTPlugin, FileCopyPlugin, FilePlugin, FloatArrayPlugin, > FloatMathPlugin, JoystickTabletPlugin, JPEGReaderPlugin, > LargeIntegers,Matrix2x3Plugin, RePlugin, SecurityPlugin, > JPEGReadWriter2Plugin, SocketPlugin, MiscPrimitivePlugin, ZipPlugin. > > And a lot of debugging. :-). > > Next step: > - fixing all the Event. > - Do a real Configuration generator to be able to generate from Jenkins using > the NDK. > - Then merge in the main PharoVM Git :-). > - Do a configuration to allow older pharo image to run on it. Maybe older but > I not convince yet. > - And obviously a job for allow anybody to create a android package with it's > own image :-) > > See you soon :-) > > > > Best Regards > Dr Arnaud > jbaptiste.arn...@gmail.com > > > > > > > >
Re: [Pharo-dev] Colorising list nodes
I do not have any idea :) I should have a deeper look at the code to remember this :) Ben On 17 Jul 2014, at 16:01, Yuriy Tymchuk wrote: > Hi guys, > > 1 more question about Spec: > > can I somehow define a color for list items. For example I want to fade out > some of them. Nautilus (as it does the same for extension methods) uses > PluggableIconListMorph, can I use existing spec models? > > Uko >
Re: [Pharo-dev] SpecInterpreter?
Not particular reason. It was coded this way because it was what we needed back at this time :) Please feel free to improve it Ben On 03 Jul 2014, at 12:52, Yuriy Tymchuk wrote: > Awesome. I’ve missed that somehow. > > While I’ve got a reply from you, can I ask one specific question? > > As Roassal’s view is the main handle to control the visualisation, why can’t > Roassal model use a View as a main property, and we have to use a script? The > thing is that if you want to change something in the view on the go, it’s > quite hard. > > Uko > > On 03 Jul 2014, at 12:42, Benjamin > wrote: > >> And you can also find some explanations here: >> http://spec.st/docs/interpreter/#collect_the_data >> >> Ben >> >> On 03 Jul 2014, at 12:37, Yuriy Tymchuk wrote: >> >>> Hi, >>> >>> is there any explanation how SpecInterpreter works? >>> >>> Because in MorphicRoassalAdapter class you have: >>> >>> defaultSpec >>> >>> ^ #(RTViewForSpec >>> whenLastEventChangedDo: #(model whenLastEventChangedBlock)) >>> >>> and I cannot find out how this symbol magic is working. >>> >>> Uko >>> >> >
Re: [Pharo-dev] SpecInterpreter?
And you can also find some explanations here: http://spec.st/docs/interpreter/#collect_the_data Ben On 03 Jul 2014, at 12:37, Yuriy Tymchuk wrote: > Hi, > > is there any explanation how SpecInterpreter works? > > Because in MorphicRoassalAdapter class you have: > > defaultSpec > > ^ #(RTViewForSpec > whenLastEventChangedDo: #(model whenLastEventChangedBlock)) > > and I cannot find out how this symbol magic is working. > > Uko >
Re: [Pharo-dev] SpecInterpreter?
the SpecInterpreter turns this into RTViewForSpec new whenLastEventChangedDo: model whenLastEventChangedBlock where model refers to the instance being currently build Ben On 03 Jul 2014, at 12:37, Yuriy Tymchuk wrote: > Hi, > > is there any explanation how SpecInterpreter works? > > Because in MorphicRoassalAdapter class you have: > > defaultSpec > > ^ #(RTViewForSpec > whenLastEventChangedDo: #(model whenLastEventChangedBlock)) > > and I cannot find out how this symbol magic is working. > > Uko >
Re: [Pharo-dev] super initialize
On 26 Jun 2014, at 11:30, Damien Cassou wrote: > On Thu, Jun 26, 2014 at 9:46 AM, Torsten Bergmann wrote: >> But the question is should we care if there may be >> in the future? > > > I think there is a lint rule that checks if #initialize calls super > initialise. on instance side only Ben > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill >
Re: [Pharo-dev] Spec Button Shortcut Indication
On 25 Jun 2014, at 20:40, Sean P. DeNigris wrote: > Benjamin Van Ryseghem (Pharo) wrote >> It’s intentional that the C is underlined. > > Cool!! One of the few good ideas from Windoze… Now we have to remove it! ;) Ben > > > - > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Spec-Button-Shortcut-Indication-tp4764414p4764778.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >
Re: [Pharo-dev] Spec Button Shortcut Indication
> The difference is the C that is underlined. Is this intentional ? It’s intentional that the C is underlined. > > Is there a way to have a shortcut, but not the underlining ? This is not planned, but it’s doable :) If you dig in ButtonModel, you should find if easily (or maybe in MorphicButtonAdapter) Ben
Re: [Pharo-dev] Auto fill free space by widget in Spec
In your morphic adapter, you probably missed hResizing: #spaceFill; vResizing: #spaceFill; Ben On 19 Jun 2014, at 13:56, Yuriy Tymchuk wrote: > Hi, I’ve implemented a custom model together with adapter. It works fine when > I open it alone with Spec, but when I include in in the other model, it > appears in a very small size and is not resizing with the window. Am I > missing any magic there? > > Uko
Re: [Pharo-dev] Complaints about Spec
I understand your frustration, but writing doc takes time. I have a more industry oriented example in polishing mode Ben On 18 Jun 2014, at 11:40, Yuriy Tymchuk wrote: > Hi guys, > > I was very frustrated, but as usually complaints are useless, I’ll try to be > constructive. Maybe the problem is not about Spec itself but all the UI > related tool-chain. > > I find UI very fragile part in software design. And by now I’ve seen only 2 > very nice documentations on how to develop UI (with MVC). One was for Ruby on > Rails, and another was for iOS applications. Documentation was > straightforward: 1) this is how your model, view and controller should look > like, 2) this is how they have to talk, 3) other useful cases. > > Now, there is description about how to do something with Spec, and it’s cool, > but for example I always get myself caught in initialisation stuff. Spec > intends that I provide some default solution if it’s not initialised with > proper data. And I even cannot initialise some variables, because > initialisation of superclass initialises widgets and they need default > behaviour. I can move to sort of lazy initialisation stuff, but maybe there > is some reason in making some calculator example tutorial that will show how > mvc apps should be developed in Pharo? > > Uko > >
Re: [Pharo-dev] [Moose-dev] CodeCity and Spec
From what I remember, it was something like: RoassalModel new script: [ :view :canvas | my roassal stuff ]; openWithSpec Or you can then embed it as any other spec model Ben On 17 Jun 2014, at 10:27, Yuriy Tymchuk wrote: > Are there any examples how to use it? I’m not a Spec guru, so any snipers are > useful :) > > Uko > > On 13 Jun 2014, at 14:34, Johan Fabry wrote: > >> Hola, >> >> AFAIK there are no plans for that. Maybe there is an alternative: there is a >> Roassal2 adaptor for Spec, Roassal2Spec package, which should now come with >> Roassal2. It allows you to have any Roassal2 visualization as a Spec >> ComposableModel. >> >> On Jun 13, 2014, at 4:47 AM, Yuriy Tymchuk wrote: >> >>> Hi all, >>> >>> are there any suggestions for integrating CodeCity into Spec? E.g. using >>> CodeCity visualisation in a view build by Spec. >>> >>> Uko >>> ___ >>> Moose-dev mailing list >>> moose-...@iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >> >> >> >> ---> Save our in-boxes! http://emailcharter.org <--- >> >> Johan Fabry - http://pleiad.cl/~jfabry >> PLEIAD lab - Computer Science Department (DCC) - University of Chile >> >> > >
Re: [Pharo-dev] Understanding the System Browser
On 07 Jun 2014, at 13:03, Nicolai Hess wrote: > > --- Part 1 --> Methods > > 1) What "Browser full" really means ? and whats the difference with plain > browsing ? > > I would say "Browse Full" is the "normal" browser, no scope and other (older) > SystemBrowser had some > special views, like hierarchy browser, version browser… That’s something like that :) Actually it opens a new browser, with the exact same state as the current one. Kind of a `Nautilus clone`. > > 7) why "rename method all" is in the main menu and in the sub menu > “refactoring" The refactoring engine comes as a plugin/layer on top of the bare Nautilus. So some actions are implemented without the refactoring engine (the `Analyse` menu) and some are implemented with the Refactoring engine. Moreover, some actions are in the main menu and the refractoring menu because it’s a refactoring often used, and you do not want 5 clicks to reach it. > > 8) "add in Group" throws me an error listmanager is nil. > > Groups are buggy, I am about to refactor and fix this. Feel free to file some > bug reports if they are missing. They use to work :P > > > -- Part 2 --> Classes > > 9) In analyze sub menu there is a "Force the generation of intialize method" > what this means ? > > generates an initialze method which calls super initialize and initialize all > instvars with nil, > helpful if you make a new subclass with additional inst vars. What you describe is `Generate initialize method`. If you already have an `initialize` method, doing `Generate initialize method` will only jump to the method, while the `Force the generation of initialize method` will empty it and fill it with the default pattern once more. > > > 10) In refactoring > coder rewriting . How all options work ? Whats their > purpose ? > They use to work, but I never use them so I can not be sure they still work :P It brings some DSL for AST manipulation. I think there is a chapter about that in PBE > > > > 11) In refactoring > class refactoring what Realize really does ? It goes for all the `shouldBeImplemented` in the superclasses, and create a method for it. It turns an abstract class into a concrete one :) Ben
Re: [Pharo-dev] NewList without Icons
On 21 May 2014, at 00:08, Nicolai Hess wrote: > Therefore, is there a way to create the NewList and tell it to NEVER > ask for icons? > As far as I remember I did not implement this option :) But having a flag for that should not be too complicated to add ;) Good luck, Ben
Re: [Pharo-dev] Confused by NewListExample
What do you think is the reaction people have reading this mail? Ben On 22 Apr 2014, at 20:53, Stephan Eggermont wrote: > - title toggling doesn’t work > - doesn’t have a usable size > - window title not set > - dragging doesn’t work > - disallows selection in one place, > allows it somewhere else > - menu the same on list title > - uses halts directly instead of > calling a method on self displaying > the action (open a dialog, show a growl) > >
Re: [Pharo-dev] Pillar in TextMate
Cool :) I will definitely have a look :) Ben On 20 Apr 2014, at 08:35, Yuriy Tymchuk wrote: > Dear guys who use Pillar. > > I’m happy to announce that I’ve created a small bundle for TextMate. You can > find it here: https://github.com/Uko/Pillar.tmbundle > > Also I’ve exported it to ATOM (new editor from github) package, but it’s > crappy because ATOM lacks some stuff right not. Package is called: > language-pillar, source is here: https://github.com/Uko/language-pillar > > I will be happy to hear your feedback, and add more features. > > Happy Easter! > Uko > > P.S. (won’t be online for ≈30hours)
Re: [Pharo-dev] Bug in Spec layout?
This is a nightmare to solve :) a way to fix it is ti introduce another column for the two first widgets Ben On 09 Apr 2014, at 11:23, Martin Dias wrote: > Hello folks, > > When I evaluate in latest Pharo 3: > > DynamicComposableModel new > instantiateModels: #( > a TreeModel > b TreeModel > c TreeModel); > openWithSpecLayout: > (SpecLayout composed > newColumn: [ :column | > column > newRow: [ :row | > row newColumn: #a. > row newColumn: #b. > row newColumn: #c width: 80 ] ]; > yourself) > > ===> > > > > Maybe I'm wrong: I expected that #a and #b have the same width. But it looks > like the layout algorithm first splits the space half/half between #a and #b, > and later it only shrinks #b to give the fixed space to #c. > > Should I report an issue? or specify layout in other way? > > Thanks, > Martín
Re: [Pharo-dev] Lock-free Atomic Counter ?
I hate to bust this old evilness out, but is it feasible to abuse #become: for this purpose? I haven't used it in so long I don't actually remember whether that's feasible semantics with ivars. On Thu, Apr 3, 2014, at 09:08 AM, Levente Uzonyi wrote: > On Thu, 3 Apr 2014, Igor Stasenko wrote: > > > > > > > > > On 3 April 2014 00:11, Sven Van Caekenberghe wrote: > > Hi, > > > > Is it possible to have a simple lock-free atomic counter in Pharo 3.0 > > ? > > > > nextId > > ^ idCounter := idCounter + 1 > > > > Or is it still possible that two process entering this code can mess > > things up ? > > > > #+ is a message send. So technically, if you will be interrupted at the > > point of > > If #+ is compiled to bytecode 176, and both the receiver and the argument > are SmallIntegers, then it's not a message send, so the operation is > atomic. > > > Levente > > > returning a result from it, then somebody else could run #nextId without > > notice, > > as result you will get 2 processes returning same value from #nextId. > > (and increasing numbers of concurrent processes will produce even more > > surprising results :) > > > > I vaguely remember a discussion about that long ago... > > > > assignment is atomic.. the one which i use in atomic queue impl., but it is > > hidden, undocumented VM implementation detail :) e.g.: > > > > oldA := a. > > a := newA. > > .. > > actually can be any series of it, as long as nothing else there (no message > > sends) > > > > x:= a. > > y:=b. > > z := c. > > w := e. > > > > will be performed atomically. > > > > > > TIA, > > > > Sven > > > > > > > > > > -- > > Best regards, > > Igor Stasenko. > > > >
Re: [Pharo-dev] New Nautilus side bar buttons
On 01 Apr 2014, at 14:01, Stephan Eggermont wrote: > Ah, that’s easy. > Putting them into a plugin is left as an exercise for the reader. As well as implementing the support for plugin on sides and not only top/middle/bottom Remind me a lot of lectures I had: “Today we will see how to go on the Moon. … This was how to fill up the tank, the rest is left as an exercise” Ben
Re: [Pharo-dev] Spec and forms
Are you on Windows? Because I experienced some strange (though similar) issues on Windows (gods know why :S) Ben On 31 Mar 2014, at 23:59, Sergi Reyner wrote: > 2014-03-31 22:48 GMT+01:00 Esteban Lorenzano : > > On 31 Mar 2014, at 18:40, Sergi Reyner wrote: > >> 2014-03-31 22:36 GMT+01:00 Benjamin : >> On 31 Mar 2014, at 23:34, Sergi Reyner wrote: >>> >>> Yes, MNU MAContainerMorph>>asSpecAdapter >>> >> >> #asSpecAdapter is implemented on Morph oO >> >> But MAContainerMorph does not inherit from Morph :) >> >> Object -> Model -> MADescriptionModel -> MAContainerMorph > > no matter, this: > > ProductFamily new asMagritteMorph morph asSpecAdapter > > should produce the right result (no image opened now, so it can be slightly > different) :) > > Indeed it does. It looks slightly ugly though: > > defaultSpec > > ^ SpecLayout composed > newColumn: [ :column | > column > add: #familyList; > add: #familyEditor ]; > yourself > > > initializeWidgets > familyList := self newList. > familyEditor := ProductFamily new asMagritteMorph morph asSpecAdapter. > > produces the attached result. > > Can it be easily fixed? > > >
Re: [Pharo-dev] Spec and forms
On 31 Mar 2014, at 23:40, Sergi Reyner wrote: > > But MAContainerMorph does not inherit from Morph :) I do not know how I could have imagined that it inherited from Morph :P Ben
Re: [Pharo-dev] Spec and forms
On 31 Mar 2014, at 23:46, Sergi Reyner wrote: > 2014-03-31 22:40 GMT+01:00 Sergi Reyner : > 2014-03-31 22:36 GMT+01:00 Benjamin : > > On 31 Mar 2014, at 23:34, Sergi Reyner wrote: >> >> Yes, MNU MAContainerMorph>>asSpecAdapter >> > > #asSpecAdapter is implemented on Morph oO > > Maybe > ProductFamily new asMagritteMorph morph asSpecAdapter > > But I can't try right now, real life is kicking in :S Keep me in touch then :) Ben
Re: [Pharo-dev] Spec and forms
On 31 Mar 2014, at 23:34, Sergi Reyner wrote: > > Yes, MNU MAContainerMorph>>asSpecAdapter > #asSpecAdapter is implemented on Morph oO Ben
Re: [Pharo-dev] Spec and forms
Not yet :) I would love too, but not enough time so far :) Ben On 31 Mar 2014, at 18:51, Norbert Hartl wrote: > Is there anything that might help in order to create a form like UI in spec? > Any descriptive way? slot based? magritte? > > Norbert
Re: [Pharo-dev] Spec and forms
On 31 Mar 2014, at 19:19, Sergi Reyner wrote: > I just naïvely tried to do: > > familyEditor > ^ MorphicGenericAdapter morph: ProductFamily new asMagritteMorph > Did you try: familyEditor ^ ProductFamily new asMagritteMorph asSpecAdapter ? Ben
Re: [Pharo-dev] New Nautilus side bar buttons
It was supposed to be a plugin at the beginning, then some laziness happened, and it is not a plugin (yet) :) It also adds a lot of complexity in the morphic layout to manage this, but it’s doable :) Ben On 30 Mar 2014, at 21:29, François Stephany wrote: > Same for me, I never use them. > > I don't really care what they look like but if there is a way to exend this > area with a plugin or completely remove it from the layout, the one posting > how to do it will get a beer/coffee in Cambridge this summer. > > > On Sun, Mar 30, 2014 at 4:32 PM, Sebastian Sastre > wrote: > I must confess that I never use those buttons but yours doesn’t look broken > > so, yes: +1 > > > > On Mar 28, 2014, at 1:57 PM, Benjamin > wrote: > >> Hello guys, >> >> since I do not really like the new buttons introduced in Nautilus, >> and since the previous one were broken, I propose this new set >> of buttons based on the eclipse theme. >> >> >> >> >> Tell me what you think about it :) >> Ben >> > >
Re: [Pharo-dev] New Nautilus side bar buttons
On 28 Mar 2014, at 23:16, Nicolai Hess wrote: > Really? > > What was wrong with the old one? They look 70’ :) And the B button misses a butt :) Ben
Re: [Pharo-dev] New Nautilus side bar buttons
On 28 Mar 2014, at 19:31, Sven Van Caekenberghe wrote: > Beautiful. Thank you ! Thanks :) > But how dare you propose a change, please stop contributing, I hate people > who actually do stuff ;-) The question is not about people doing things, it’s about introducing things that are not fixes or critical. Of it is decided to not integrate this in 3.0, I am totally fine with it as the buttons work (even if they look bad). Ben
Re: [Pharo-dev] New website about Spec - http://spec.st
On 28 Mar 2014, at 14:43, Pharo4Stef wrote: > What is the best github repo to edit the chapter? https://github.com/spec-framework/documentation, since I would like to gather as much as possible all the things related to spec at only one place :) Ben
Re: [Pharo-dev] New Nautilus side bar buttons
On 28 Mar 2014, at 18:24, p...@highoctane.be wrote: > Too bad, we'll have to wait for 4.0 (or 3.1 to get them…) As it is actually fixing something, maybe it will make it :) > Jokes aside, they are very nice. And I want them. > Where is the slice? https://pharo.fogbugz.com/default.asp?13151 Ben
Re: [Pharo-dev] Release Mode
On 28 Mar 2014, at 17:30, Stephan Eggermont wrote: > Philippe wrote >> The look of nautilus button isn't "ok to integrate" since there is much more >> work needed to get this working properly. > > That’s two different issues. One is integrated, the other not. > 13137 The SBIC buttons change is ok, afaik. No it’s not ok. It looks really bad, and really far from anything else Ben > 13135 exposes lot’s of issues in the tools. All kinds of off-by-ones in > sizes. > > I also prefer the scrollbar fixes (13136) > > Stephan
Re: [Pharo-dev] New website about Spec - http://spec.st
On 28 Mar 2014, at 16:57, p...@highoctane.be wrote: > Sorry about that. It wasn't intentional. No problem :P It motivated me to finish fast :P > Superb work. And I want that dark theme :-) Me too :P Ben
Re: [Pharo-dev] New Nautilus side bar buttons
On 28 Mar 2014, at 18:24, MartinW wrote: > Just out of curiosity (this is not a rhetoric question, i just don't know it) > - when should i look at the byte code? That’s a good question :) I usually look at byte code when I have strange compilation errors. > And are there enough use cases to justify such a very prominent place in the > UI? I do not know if it needs such an important place, that’s true. Maybe we should think about it for Pharo 4.0 :) Ben
[Pharo-dev] New website about Spec - http://spec.st
Hi guys :) I am glad to announce (even if Philippe already let the cat out :P) a website dedicated to Spec: http://spec.st. You can find a quick introduction, documentation (mainly what is now in the Pharo For The Enterprise book), and a news feed where I will explain the API changes, the news widgets introduce etc. The website contents can be found here (https://github.com/spec-framework/website) so if you want to contribute you are welcome :) Ben PS: I would like to thank Johan Fabry who helped me a lot writing the documentation, Sean P. DeNigris who fixed my english a couple of times and Nicolas Petton who helped me on the website look and feel
Re: [Pharo-dev] Use Spotlight to quickly evaluate and inspect short expressions
I would love to have it the other way around: that Alfred can browse a Pharo image :) Ben On 25 Mar 2014, at 14:41, Tudor Girba wrote: > Excellent! > > This goes in the direction of Alfred or Quicksilver. I worked on a design (no > implementation yet) that goes in the same direction. I think we definitely > need to get more in this direction, and that we should make it easy for > people to hook their own matchers. For example, when I start something with / > or ./ I would like to inspect the file with that name. > > Doru > > > On Tue, Mar 25, 2014 at 2:30 PM, Sven Van Caekenberghe wrote: > I had this idea: > > https://pharo.fogbugz.com/f/cases/13128/Use-Spotlight-to-quickly-evaluate-and-inspect-short-expressions > > now you can do > > :42 > > to inspect the magic number 42 > > :1500*1.25 > > to quickly compute your 25% raise > > :Float pi > > to see how many decimals you still remember > > :ZnClient new get: 'http://zn.stfx.eu/zn/small.html' > > and so on. > > The interaction with the completion menu is not 100% perfect, but pressing > at the end before solves that. > > Feedback ? > > Sven > > PS: I know that many Smalltalk greybeards type everywhere to the same effect, > and that is cool to, but it leaves around dirty windows. Opening a workspace > for a single expression often is overkill. This feature is totally keyboard > driven and very clean. > > PS2: Yes it resembles Emacs' M-: (evaluate-expression), but Pharo is much > cooler, right ;-) > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"
Re: [Pharo-dev] Using Spec based UI in Nautilus Plugins
MethodToolbar new buildWithSpec Ben On 25 Mar 2014, at 10:09, p...@highoctane.be wrote: > This doesn't work for building the MathodToolbar widget. > > MethodToolbar defaultSpec buildWithSpec > > #DNU SpecLayout>>buildWithSpec > > MethodToolbar class>>defaultSpec > > ^ SpecLayout composed > newRow: [ :row | > row > add: #(model browseModel); > add: #(model sendersModel); > add: #(model implementorsModel); > add: #(model versionModel); > add: #(model dropListModel) ]; > yourself > > > > What to do? > > Phil > > On Tue, Mar 25, 2014 at 9:51 AM, Benjamin > wrote: > You create your own subclass of AbstractNautilusPlugin in where the display > method will look like > > display > ^ mySpec buildWithSpec > > This should do the trick > > Ben > > On 25 Mar 2014, at 08:41, p...@highoctane.be wrote: > >> I wanted to use a MethodToolbar as part of a Nautilus plugin. >> >> Ok, I can use the widget in with an openWithSpec but how can I put this into >> a widget that Nautilus will accept as a plugin? >> >> >> | b | >> b := MethodToolbar new. >> b openWithSpec. >> b method: >> >> >> Phil >> > >
Re: [Pharo-dev] Using Spec based UI in Nautilus Plugins
You create your own subclass of AbstractNautilusPlugin in where the display method will look like display ^ mySpec buildWithSpec This should do the trick Ben On 25 Mar 2014, at 08:41, p...@highoctane.be wrote: > I wanted to use a MethodToolbar as part of a Nautilus plugin. > > Ok, I can use the widget in with an openWithSpec but how can I put this into > a widget that Nautilus will accept as a plugin? > > > | b | > b := MethodToolbar new. > b openWithSpec. > b method: > > > Phil >
Re: [Pharo-dev] Nautilus keyboard behavior
On 22 Mar 2014, at 21:48, p...@highoctane.be wrote: > Ctrl-Fn-F2 opens the Apple menu. This is not a contextual menu Ben
Re: [Pharo-dev] Nautilus keyboard behavior
On 20 Mar 2014, at 21:38, Stephan Eggermont wrote: > That doesn’t work for me. (Mavericks mac, 30798 with slice 13100) I will have a look then :) > Ah found them. cmd-t-g cmd-t-p cmd-t-h > Let me rephrase that: can we have a way to discover that? Perhaps info on > hover or so? There is a helper in the window menu (black arrow in the top rift corner) with the list and description of all the shortcut available :) Ben
Re: [Pharo-dev] Check if CompiledMethod sends to self
On 20 Mar 2014, at 18:45, Yuriy Tymchuk wrote: > Hi everyone. > > I need to check if a method sends anything to self. There is a method > #sendsToSuper, but I don’t really know how can I search for self reference in > a same way. Can anybody suggest me where can I learn this? I did something like that with Alex :) The code is here: http://smalltalkhub.com/#!/~BenjaminVanRyseghem/PrivacyChecker/ You can have a look at the class SelfSendCollector. Basically it creates the AST of the method, and visit it to collect the self sends Hope it helps, Ben
Re: [Pharo-dev] List editor spec widget
On 20 Mar 2014, at 18:13, Yuriy Tymchuk wrote: > Should this be an extension of List with buttons, of a buttons widget that > has a setters for the list to modify and the block for retrieving the rest of > items (during the addition action) Sorry I do not understand your question :) But I think the answer is Make a complete new widget, with one list and two buttons, and enough methods to tweak the buttons and the list :) You could even have a dedicated widget for the buttons, so one can replace them with a special new “buttons toolbar” widget Hope it helps, Ben
Re: [Pharo-dev] Nautilus keyboard behavior
On 20 Mar 2014, at 15:48, Stephan Eggermont wrote: > 13100 triggered me to take a look at keyboard based navigation > in Nautilus. These should probably be a number of different issues. > > There seems to be no way to get from the text pane back to > methods-categories-classes-packages , both tab and right-arrow > are captured. > cmd+crt+left/right arrow > How do I open the menu on one of the top panes in Nautilus? Do you need menu when you have shortcut for menu items? Can you give me example of application where one can open a contextual menu whiteout the mouse (in OSX you cannot). > How do I open the History navigator? By tabbing to it and pressing arrow down? > I’d expect groups and hierarchy to be selectable with a key combination > when the packages pane is selected. They are Ben
Re: [Pharo-dev] Couchbase client
On Tue, Mar 18, 2014, at 07:06 PM, Esteban A. Maringolo wrote: > I don't know the exact difference between the clients of Couchbase and > CouchDB. > > I know Couchbase forked from CouchDB, and the REST API is the same. > Hopefully the CouchDB client will work. It probably won't. Couchbase's protocol is basically memcache (and you can indeed use a memcache library to talk to Couchbase in a pinch), whereas CouchDB uses a REST protocol over HTTP. I know there used to be at least one memcache client on Squeaksource; I'd probably see if it's migrated to SmalltalkHub or similar. --Benjamin
Re: [Pharo-dev] List editor spec widget
On 15 Mar 2014, at 22:39, Yuriy Tymchuk wrote: > Hi everyone. > > I wander if there is already something like the list editing buttons in OS X > i.e. ‘+’ and ‘-‘ buttons that either open a dialog with another list that > allows to select what to add, or remove selected items from the list. > (example on screenshot). I would answer “not yet” :) Feel free to submit one :P If you have questions, I will be glad to answer them, and to help you to propose such a widget, reusable enough so we can add it to the spec widgets :) Ben
Re: [Pharo-dev] Komitter does not display correctly
Fixed Ben On 14 Mar 2014, at 11:53, Serge Stinckwich wrote: > In the last version of Pharo, Komitter does not work correctly. > Modifications done under packages are not displayed. > > Apparently the problem appears at #30789: > https://github.com/pharo-project/pharo-core/commit/802360955460a9a8d9284c8727e2ac3f88d2bc01 > > I guess something related to this spec fix: > https://pharo.fogbugz.com/f/cases/13040 > > Regards, > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ >
Re: [Pharo-dev] Komitter does not display correctly
Reported here: https://pharo.fogbugz.com/default.asp?13077 Fix on its way :) Ben On 14 Mar 2014, at 11:53, Serge Stinckwich wrote: > In the last version of Pharo, Komitter does not work correctly. > Modifications done under packages are not displayed. > > Apparently the problem appears at #30789: > https://github.com/pharo-project/pharo-core/commit/802360955460a9a8d9284c8727e2ac3f88d2bc01 > > I guess something related to this spec fix: > https://pharo.fogbugz.com/f/cases/13040 > > Regards, > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ >
Re: [Pharo-dev] Spec double title or nil title
I will review it within the week end :) Ben On 14 Mar 2014, at 08:22, Freemail wrote: > On Fri Mar 14 07:28:32 2014 roberto.mine...@usi.ch > wrote: > > Hi Guys, > > > > I noticed a weird behavior of Spec MenuModel, it has either a double > > title or a #nil title. > > > > Please see > > https://pharo.fogbugz.com/f/cases/13075/Spec-double-title-or-nil-title > > > > Cheers, > > R > > There is a fix for issue 13064 "nil as menutitle (inspector menu)". > It is ready for integration and just needs a review. > > Nicolai >
Re: [Pharo-dev] ComposableModel>>initialExtent
Sounds good :P I will integrate it into Spec dev (I think it’s safer for now to not remove it into Pharo since it’s frozen) Ben On 12 Mar 2014, at 19:04, Laurent Laffont wrote: > As far as I see, it seems safe to remove ComposableModel>>initialExtent > Spec tests green, TWM tests green and I haven't seen any problem yet. What do > you think ? > > Laurent > > > Le mercredi 12 mars 2014, 17:36:20 Benjamin a écrit : >> The first answer is: >> ComposableModel was not a subclass of model at first :P >> >> >> Ben >> >> On 12 Mar 2014, at 13:09, Laurent Laffont wrote: >> >>> Hi, >>> >>> I'm trying to have tests green for TWM. I found: >>> >>> ComposableModel>>initialExtent >>> ^ nil >>> >>> on superclass Model there's >>> >>> Model>>initialExtent >>> ^ RealEstateAgent standardWindowExtent >>> >>> that sounds good. So I don't understand why ComposableModel redefine >>> #initialExtent to answer nil. Any explanation ? >>> >>> Laurent >>> >> >
Re: [Pharo-dev] ComposableModel>>initialExtent
The first answer is: ComposableModel was not a subclass of model at first :P Ben On 12 Mar 2014, at 13:09, Laurent Laffont wrote: > Hi, > > I'm trying to have tests green for TWM. I found: > > ComposableModel>>initialExtent > ^ nil > > on superclass Model there's > > Model>>initialExtent > ^ RealEstateAgent standardWindowExtent > > that sounds good. So I don't understand why ComposableModel redefine > #initialExtent to answer nil. Any explanation ? > > Laurent >
Re: [Pharo-dev] [ANN] RenoirSt 1.0.0 Release for Pharo 3.0
The usage of Github pages makes it look like http://spec.st/ :P Ben On 11 Mar 2014, at 14:13, Gabriel Cotelli wrote: > Hi, > > I'm announcing the first official release of RenoirSt, a DSL enabling > programmatic cascading style sheet generation for Pharo. > > For the impatient, you can load it in your 3.0 image evaluating: > > Gofer it > url: 'http://smalltalkhub.com/mc/gcotelli/RenoirSt/main'; > configurationOf: 'RenoirSt'; > loadStable > > or download a ready to use image from the Contribution CI Server ( a > ConfigurationBrowser option comming soon). > > Visit the project page and GitHub repository for more information on the > supported and planned features, and check-out the online tutorial. > > I hope you find it useful. Feel free to ask any questions, suggest ideas and > improvements, or report bugs (the issue tracker is in GitHub). > > Gabriel
[Pharo-dev] About a Spec dedicated mailing-list
Hello guys :) I was wondering if it will make sense to have a spec dedicated mailing list :) As I have pros and cons, I am asking for your opinion :) Thanks in advance, Ben
Re: [Pharo-dev] MenuRegistration is probably missing a MenuGroupSpec object
That’s exactly the reason why one was introduced in Spec :) Ben On 05 Mar 2014, at 12:05, Pharo4Stef wrote: > When I see this code, I think that we are missing a MenuGroupSpec to work > with MenuSpec > and we could also rename PluggableMenuSpec into MenuSpec. > > > buildMenuSpec: aMenu > "recursiveley build the menu spec aMenu passed as argument" > self itemList > ifNotNil: [:l | > | m | > m := isGroup > ifFalse: [PluggableMenuSpec withModel: nil] > ifTrue: [aMenu]. > (l reject: [:i | i precondition value not]) do: [:i | i > buildMenuSpec: m]. > isGroup ifFalse: [self spec subMenu: m]]. > isGroup > ifTrue: [self spec separator ifTrue: [self itemList ifNotNil: > [self itemList last spec separator: true]]] > ifFalse: [aMenu items add: self spec] > > > https://pharo.fogbugz.com/default.asp?13044
Re: [Pharo-dev] Spec #subMenu is broken
On 05 Mar 2014, at 08:41, Pharo4Stef wrote: > where? because I wanted to integrate it and I could not find the slice in the > inbox. PharoInbox, slice number 13040 It’s weird you do no find it :S > > did you fix also the menu title rendering (when putting a title it was not > used and rendered) > because I was hacking a solution in the “MenuAdapter” but I do not remember > where I put the code. I do not remember such an issue :( > I will dig the code and publish it, if it is not fixed. Cool, tell me :) Ben
Re: [Pharo-dev] Spec #subMenu is broken
I proposed a new update for Spec with this fix in it :) Ben On 04 Mar 2014, at 18:38, roberto.mine...@usi.ch wrote: > Cool Ben! > > P.s. Should I wait until the fix will be integrated in Pharo? > > Cheers, > R > > On Mar 4, 2014, at 5:13 PM, Benjamin > wrote: > >> Thanks for the report :) >> >> Fixed in commit df6e44a :) >> >> Ben >> >> On 04 Mar 2014, at 16:57, roberto.mine...@usi.ch wrote: >> >>> Hi, >>> >>> It seems that Spec’s #subMenu functionality is broken. >>> >>> I opened an entry here: >>> https://pharo.fogbugz.com/f/cases/13039/Spec-s-subMenu-is-broken >>> >>> Cheers, >>> RM >> > >
Re: [Pharo-dev] Spec #subMenu is broken
Thanks for the report :) Fixed in commit df6e44a :) Ben On 04 Mar 2014, at 16:57, roberto.mine...@usi.ch wrote: > Hi, > > It seems that Spec’s #subMenu functionality is broken. > > I opened an entry here: > https://pharo.fogbugz.com/f/cases/13039/Spec-s-subMenu-is-broken > > Cheers, > RM
Re: [Pharo-dev] UX problem in debugger
On 04 Mar 2014, at 11:15, Sven Van Caekenberghe wrote: > A simple, quick solution would be to do an #inform: telling what was written > where. In Pharo this then becomes a growl like non-obstrusive thing. Sounds more like a hack than a solution :) Ben
Re: [Pharo-dev] git and metacello
On 28 Feb 2014, at 10:23, Yuriy Tymchuk wrote: > Can you share a script? Because as far as I understand, You test on read-only > staff, and then link you "the one” repo on your machine. Exactly :) Here is the script to build spec: https://github.com/spec-framework/spec/blob/master/install_Spec.sh My preference to link Spec repo is: https://gist.github.com/BenjaminVanRyseghem/9268250 Ben
Re: [Pharo-dev] git and metacello
On 28 Feb 2014, at 09:53, Goubier Thierry wrote: > > [1] Ok, still, maybe there is a point there: the path to the repository clone > may well be encoded as an absolute path, and, therefore, moving the directory > elsewhere could be tricky. This is something I can look into if you choose > that git workflow. > I use preferences for that. It takes all the repo matching Spec* and add a repo pointing to my local git repo Ben
Re: [Pharo-dev] [OT] Where should menues go ...
On 23 Feb 2014, at 11:44, MartinW wrote: > > The difference of Pharo (and it's UI!) was what lured me into it, not what > constituted a barrier :) And while i would also make a case for difference > only for it's own sake, i think there are very good reasons for the pop-up > menus. They are very good reasons for popup menus. The work menu is not one of them Popup menus should (mainly) be used to propose contextual options. Now take a random menu in Pharo, and look for the items that applies only in the current context. That’s also the reason why the menu are far too long. Ben
Re: [Pharo-dev] Multiple-selection drag-and-drop
This works: m := TreeModel new. m roots: #(1 2 3 4 5). m dragEnabled: true. m dropEnabled: true. m transferBlock: [ :p :s | TransferMorph withPassenger: s model selectedItems from: s ]. m multiSelection: true. m openWithSpec. I guess the same applies for the other model, aka, redefining the TransferMorph. I am currently working on a TransferModel to hide the morphic part of it, but it will not be in Pharo 3.0. Ben On 21 Feb 2014, at 12:28, Martin Dias wrote: > Hi, > > I'm looking for a "kind-of-list" spec model (or morph) in Pharo 3 that > supports multiple-selection drag-and-drop. I tried with TreeModel, > NewListModel and ListModel... they don't support. > > Note: NewListModel even doesn't support single-selection drag-and-drop... is > this a known issue or should I report it? > > Thanks, > Martín
Re: [Pharo-dev] Desktop Apps with Pharo 3
On 18 Feb 2014, at 17:26, Noury Bouraqadi wrote: > Hi, > > For my Pharo Lecture I want to show students how to make a desktop app in > Pharo 3.0 (Yes I'm using a Beta for my lecture, because Pharo 3 is cool :-) > > - I wonder if there are any new cool solution to strip out dev tools or at > least lock the world menu? To prevent the current user to open debuggers: Smalltalk tools userManager currentUser permissions canDebug: false. (pay attention to not prevent yourself to execute code :P) > > - Is there any way to set the OS window size other than simply turning it > full screen? DisplayScreen hostWindowSize: ext Ben
Re: [Pharo-dev] how to Initialize class layouts
There was (is?) a Slot virus that, if I remember correctly, was in charge of propagating the slot layout instantiation. Ben On 16 Feb 2014, at 16:13, Pavel Krivanek wrote: > Hi, > > the classes in bootstrapped image have no layouts set. We must initialize > them somehow because than class builder fails. Is there the code that did > this task during Slot integration somewhere? Or can someone erudite tell us > how to do that? > > Cheers, > -- Pavel
Re: [Pharo-dev] Request
You can also try Faster than Light (http://www.ftlgame.com/) Its a cool game :P Ben On 14 Feb 2014, at 23:24, olivier auverlot wrote: > Hi Guido, > > You can try "Faster than Light". This is a pool connection to open multiple > sockets. The project is on Smalltalkhub > (http://smalltalkhub.com/#!/~RMoD/FasterThanLight). It works with Pharo 2.0, > not tested with 3.0 > > Olivier ;-) > > > > > 2014-02-13 15:20 GMT+01:00 : > Guido Chari wrote: > > Hi guys, > > I´m doing some experiments with dynamic primitives and files. > Actually i am working with the socket and file plugin. (In that order of > priority) > > Does anyone know about an open pharo app that make heavy use of sockets > (mainly creating lot) that i can borrowed (install locally) for doing serious > experiments? Something with heavy used of files will help too. > > Thanks, > Best, > Guido. > > SmalltalkHub? > > >
Re: [Pharo-dev] Versionner Suggestions
On 13 Feb 2014, at 19:51, Sean P. DeNigris wrote: > 12877 Versionner: Make Project Editing More Prominent > https://pharo.fogbugz.com/default.asp?12877 > It wasn't immediately obvious to me that I had to double click on a project > to edit the configuration. Maybe we should add a button? At minimum, it > should be added to the context menu… I made the exact same suggestion to Christophe this afternoon :) Ben
Re: [Pharo-dev] GSoC: call for ideas
On 11 Feb 2014, at 17:28, Yuriy Tymchuk wrote: > > C’est cool. Thank you Ben. I had some more ideas like making a common STON > format for prefs. But maybe you have some more ideas. Or we can just kill > this proposal.\\ Maybe we should discuss it then :) Ben
Re: [Pharo-dev] GSoC: call for ideas
On 11 Feb 2014, at 16:51, Yuriy Tymchuk wrote: > > On 11 Feb 2014, at 16:49, Benjamin > wrote: > >>> 4. Preferences persistence. >>> Now prefs are only working while you are on the same image. We can put >>> a button: save for all images, and serialise prefs to conf. folder when >>> this button is checked. The same goes for user name. Why not to put >>> checkbox: “Save for all next images”. This way we won’t have a lot of >>> clones in monticello and make user’s life easier. You can use a startup >>> scripts, but this is not cool. >>> easy - advanced >>> Yuriy Tymchuk >> >> In Settings there is a button Export which (should) export all you settings >> into your preferences file and therefore be spread among images. > > Did you implement it? I did, months ago :) Ben > > Uko > >> >> Ben >> >
Re: [Pharo-dev] GSoC: call for ideas
> 4. Preferences persistence. > Now prefs are only working while you are on the same image. We can put > a button: save for all images, and serialise prefs to conf. folder when this > button is checked. The same goes for user name. Why not to put checkbox: > “Save for all next images”. This way we won’t have a lot of clones in > monticello and make user’s life easier. You can use a startup scripts, but > this is not cool. > easy - advanced > Yuriy Tymchuk In Settings there is a button Export which (should) export all you settings into your preferences file and therefore be spread among images. Ben
Re: [Pharo-dev] [gsoc-mentors] [GSoC ideas] Pharo
Porting Spec from Pharo to Amber. This can include finishing an Amber widget library named Moka, as well as porting Spec to Amber and plug it by default on Moka. Dialects involved: Pharo, Amber Skill level: Intermediate Mentors: Benjamin Van Ryseghem ( benjamin.vanryseg...@gmail.com ) and Nicolas Petton >Please include a summary of the project and links to web pages that can > help prospective students to write their application. Please also include > the following information: > >- if applicable, other dialects that you would be willing to > mentor this project for > >- the skill level > >- name of the mentor(s), email addresses, and possibly any IRC > network/channel/nickname where they can be found. Ben & Nico
Re: [Pharo-dev] Difficult to Track Changes
This change occurred like 6 months ago :) (ok maybe 3 :P ) And this is not related to NewList at all Ben On 09 Feb 2014, at 07:57, Sean P. DeNigris wrote: > It seems ListComposableModel was replaced by ListModel in Pharo 3.0. This is > a significant non-backward-compatible change, yet it was extremely difficult > to find out what was going on - no hits searching the mailing lists and the > Issue "10462: Add SpecModel for NewList" says nothing about removing > ListComposableModel. I think it's important to think "how are users going to > figure out wth happened here" when we make changes like this. > > > > - > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Difficult-to-Track-Changes-tp4742400.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >
Re: [Pharo-dev] Who invented Nautilus Groups (DynamicGroup/DynamicClassGroup)
On 03 Feb 2014, at 20:57, Nicolai Hess wrote: > I don't get why a DynamicGroup manages a list of methods and not a list > of classes like DyanmicClassGroup. Me for the title. And to answer shortly, to have groups with a finer grained definition. > If Nautilus tries to create the class list from a DyanicGroup group it takes > awful long time if this Groups have more than 20-30 different classes Then maybe the correct kind of group should be used. Ben
Re: [Pharo-dev] When code performs super...
On 03 Feb 2014, at 16:26, Norbert Hartl wrote: > I just wanna share my newest finding in producing endless loops. > > foo >super perform: #foo > > Somehow I like it! :) Should confuse a lot of JAVA-ist :P Ben
Re: [Pharo-dev] [Review]: Case 12737 Morph sends mouseUp twice to handlers
I will have a look tomorrow :) (right now, with the jet lag and the very long flight, I do not trust my brain :) ) Ben On 01 Feb 2014, at 23:07, Sean P. DeNigris wrote: > On Feb 1, 2014, at 5:04 PM, "Benjamin Van Ryseghem-2 [via Smalltalk]" > <[hidden email]> wrote: > > Do we put in in 3.0? > > > > Because changing Morphic now sounds a bit shaky to me :) > That's why I'm asking for a lot of input. But it is a bug. And I think this > slice version is very unlikely to break anything - 2 lines changed. I'd at > least appreciate someone taking a look. If you agree that it's a > straight-forward change, I will take responsibility for getting it right or > reverting. > > Cheers, > Sean > > View this message in context: Re: [Review]: Case 12737 Morph sends mouseUp > twice to handlers > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] [Review]: Case 12737 Morph sends mouseUp twice to handlers
Do we put in in 3.0? Because changing Morphic now sounds a bit shaky to me :) Ben On 01 Feb 2014, at 22:55, Sean P. DeNigris wrote: > Sean P. DeNigris wrote >> https://pharo.fogbugz.com/default.asp?12737 > > I did a safer fix which is much less likely to break other things and still > fixes the problem. Two people looked at it and the monkey validated it. > Should I "Fix to include" or would a core dev like to have a quick look > first. I'm being extra cautious because it is inside Morphic... > > > > - > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Review-Case-12737-Morph-sends-mouseUp-twice-to-handlers-tp4740026p4740923.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >
Re: [Pharo-dev] Please keep your cool new stuff for Pharo 4
On 31 Jan 2014, at 13:29, b...@openinworld.com wrote: > For instance, I've recently submitted a slice for [1] that adds two new > methods and a trivial refactoring of one other to Spec's ComposableModel (so > I can't imagine it would break anything), but in support of discipline on the > feature freeze, I could get by with making these PharoLauncher extensions for > now and hold them over to Pharo4.0. > [1] > https://pharo.fogbugz.com/f/cases/12677/subscribe-to-window-closed-event-outside-of-initialize Spec is actually hold beside Pharo3 now for this exact reason :) So things can continue to be integrated into Spec but not Pharo. And Spec bugfix for Pharo can then also be pushed into Spec. Ben PS: I will review your code within the week end, I am now at the Santiago airport waiting for a 14h long flight :)
Re: [Pharo-dev] Where to report bugs?
On 29 Jan 2014, at 18:52, Pharo4Stef wrote: > > Still many different agendas busy time. > It does not mean no interest it means that people are busy. If we wait someone has nothing to do, it will never happen :) > But since we all know that we will not move before the release then there is > not much point for people > to look at them because they are busy. When we will decide that this is time > to look then the right people > will do it. And I was sad that we would have to throw away all the time you > spend on it. Except that if we want to change at the same time we release, we should start having a look now. And I do not care throwing away what I did, that’s life :P > Yes but again busy. > VM, > jenkins > Mate > PhD > Papers > coding > Nautilus > bug fixes > everybody needs free cycles and since december none of us have. > but this is orthogonal to no interest. But it’s a matter of priority. > >>> We do not change the commit tools >>> either. > > This was related to the git story Again, if we want to change soon after the release we should not start to thing about it two month after. Ben
Re: [Pharo-dev] Where to report bugs?
On 29 Jan 2014, at 18:19, Pharo4Stef wrote: > Ben > > - creating a company > - being the head of a research group > - HDR of noury > - PhD of Nick > - Papers there and there > - admin there and there > - dealing with people > - dealing with people > - dealing with people > - having a door always open > - having a door always open > - being second of a lab of 300 researchers > - coding on boring stuff > - working on projects > - thinking about money for the team How many people are doing this? How big is the team? > is a long list of duties before even thinking about Pharo. > > So we must evaluate our energy before changing to a new architecture. > And there are always pros and cons. > > Evaluating for REAL a new bugtracker is not something that we do in one > afternoon. Yes I know, that is exactly why I did not send the mail this morning but more than a month ago. > And we do not do that two months before a release. No indeed, but you do it the day after the release. And as you say, it does not take one afternoon to get an idea if it is good or not. > We do not change the commit tools > either. ?? Ben
Re: [Pharo-dev] [Review]: Case 12737 Morph sends mouseUp twice to handlers
Filters > My case s(2nd item) Ben On 29 Jan 2014, at 18:05, Pharo4Stef wrote: > Thanks > It reminds a really strange bug I got showing that there were hidden useless > calls. but I cannot find if I entered an entry. > Any idea how I can find the entries that I added to fogbogz > > Setf > On 29 Jan 2014, at 02:47, Sean P. DeNigris wrote: > >> https://pharo.fogbugz.com/default.asp?12737 >> >> DoIt: >> Morph new >> on: #mouseUp send: #inspect to: 1; >> openInWorld. >> Two inspectors will appear. >> >> Fix in inbox: >> SLICE-Issue-12737-Morph-sends-mouseUp-twice-to-handlers-SeanDeNigris.1 >> Please review. It definitely fixes the problem, but it fiddles around inside >> Morphic so... >> Test included - fails before, passes after >> >> >> >> - >> Cheers, >> Sean >> -- >> View this message in context: >> http://forum.world.st/Review-Case-12737-Morph-sends-mouseUp-twice-to-handlers-tp4740026.html >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> > >
Re: [Pharo-dev] Where to report bugs?
I actually proposed few replacement one month ago inside the RMoD team, nobody answered except “Fogbugz is bad” , and nobody tried what I proposed. Exactly what happened when we had to choose a replacement for Google Issue Tracker. Ben On 29 Jan 2014, at 08:33, Marcus Denker wrote: > > On 29 Jan 2014, at 11:32, Sebastian Sastre > wrote: > >> I hope we’re not making it harder than it should for fear to feedback >> >> > > It has already been concluded that fogbugz was a mistake. It’s just not made > for an open source project. > > Now moving will be *a lot* of work and we have not even found a replacement > that is scriptable. > > We first need to release Pharo3 before we sink indefinite amounts of time > into this. > > Marcus
Re: [Pharo-dev] Issues 12717 and 12684
On 28 Jan 2014, at 13:53, Pharo4Stef wrote: > Ben > > I still think that it would have been good to discuss the valueHolder changes > in Spec > before doing it. This has been discussed for 2-3 days before I made it actually. > Because it broke the tools of people that used Spec like martin and clement > as well as the documentation ignaccio wrote. We should be cautious about > other people too. It actually did not break anything. And it had been reverted two days ago Ben
Re: [Pharo-dev] strange error in latest 3.0 -
It’s a duplicate of a closed issue (recently integrated by Sven) We should maybe join forces :) Ben On 28 Jan 2014, at 12:41, Martin Dias wrote: > Done. > https://pharo.fogbugz.com/f/cases/12731/Traits-modifications-cause-a-DNU > > > > On Tue, Jan 28, 2014 at 2:13 PM, Tudor Girba wrote: > Thank you! I can review it tomorrow morning. > > Doru > > > On Tue, Jan 28, 2014 at 2:10 PM, Martin Dias wrote: > hhahah, ok, I'm on it > > > On Tue, Jan 28, 2014 at 2:06 PM, Tudor Girba wrote: > Yes, please! > > Doru > > > On Tue, Jan 28, 2014 at 2:04 PM, Esteban Lorenzano > wrote: > yes, please :) > > On 28 Jan 2014, at 13:47, Martin Dias wrote: > >> >> So, what to do? >> - Don't send ClassModifiedClassDefinition in >> SystemAnnouncer>>traitDefinitionChangedFrom: oldTrait to: newTrait ? >> - Implement Trait>>layout ? >> - Test for oldClassDefinition isTrait in >> ClassModifiedClassDefinition>>isPropagating ? >> >> >> >> I discussed with Camille and we think it's better this other alternative: to >> fix class builder to only announce ClassModifiedClassDefinition for the >> class that really changed its definition. For the subclasses, it won't be >> announced. This way, it's not necessary to check if it is a propagation. We >> can remove the two implementors and the unique sender. >> >> I verified that this was the behavior of "old class builder" (in Pharo 2). >> Do you agree? >> >> I can submit a slice this afternoon. >> >> Martín > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >
Re: [Pharo-dev] Issues 12717 and 12684
Thank you for your motivation :) Ben On 27 Jan 2014, at 20:57, Sven Van Caekenberghe wrote: > Yes, I just tested: > > UserManager instVarNamed: 'default' put: nil. > UserManager initialize. > > fixes the release tests. > > I have to go to bed though ;-) > > Thx! > > Sven > > On 28 Jan 2014, at 00:54, Benjamin > wrote: > >> I think the fix https://pharo.fogbugz.com/default.asp?12711 might need to be >> applied again >> >> Ben >> >> On 27 Jan 2014, at 20:33, Sven Van Caekenberghe wrote: >> >>> >>> On 28 Jan 2014, at 00:18, Sven Van Caekenberghe wrote: >>> >>>> OK, I will try and trust you and Sean. >>> >>> Well, it is in 30 726, but there are 2 regressions found: >>> >>> ReleaseTests.ReleaseTest.testObsoleteClasses >>> ReleaseTests.ReleaseTest.testUnknownProcesses >>> >>> on all 3 platforms, these might be transient, but with all the renaming >>> something could have gone wrong >>> >>>> On 28 Jan 2014, at 00:13, Benjamin >>>> wrote: >>>> >>>>> On 27 Jan 2014, at 20:08, Sven Van Caekenberghe wrote: >>>>>> Are the compatible ? >>>>>> Does one have to come before the other ? >>>>>> Are they both needed ? >>>>> >>>>> I think we should drop >>>>>> https://pharo.fogbugz.com/f/cases/12717/ReactiveVariable-NewValueHolder >>>>> >>>>> and integrate >>>>>> https://pharo.fogbugz.com/f/cases/12684/NewValueHolder-Enhancements >>>>> >>>>> For at least two reasons: >>>>> - I added hooks for Spec to continue working with the slice I proposed >>>>> (otherwise no more Spec fix until the release) >>>>> - I do not have to review it :P >>>>> >>>>> Ok maybe the second point is not that relevant LOL >>>>> Just that I am sure that the fix I proposed works well with Spec. >>>>> And I an pretty sure the other will break it :) >>>>> >>>>> I was not aware of another case related to this. >>>>> It is not flagged Spec nor my name, so there is no way for me to guess it >>>>> exists. >>>>> >>>>> Ben >>>> >>> >>> >> > >
Re: [Pharo-dev] Issues 12717 and 12684
I think the fix https://pharo.fogbugz.com/default.asp?12711 might need to be applied again Ben On 27 Jan 2014, at 20:33, Sven Van Caekenberghe wrote: > > On 28 Jan 2014, at 00:18, Sven Van Caekenberghe wrote: > >> OK, I will try and trust you and Sean. > > Well, it is in 30 726, but there are 2 regressions found: > > ReleaseTests.ReleaseTest.testObsoleteClasses > ReleaseTests.ReleaseTest.testUnknownProcesses > > on all 3 platforms, these might be transient, but with all the renaming > something could have gone wrong > >> On 28 Jan 2014, at 00:13, Benjamin >> wrote: >> >>> On 27 Jan 2014, at 20:08, Sven Van Caekenberghe wrote: >>>> Are the compatible ? >>>> Does one have to come before the other ? >>>> Are they both needed ? >>> >>> I think we should drop >>>> https://pharo.fogbugz.com/f/cases/12717/ReactiveVariable-NewValueHolder >>> >>> and integrate >>>> https://pharo.fogbugz.com/f/cases/12684/NewValueHolder-Enhancements >>> >>> For at least two reasons: >>> - I added hooks for Spec to continue working with the slice I proposed >>> (otherwise no more Spec fix until the release) >>> - I do not have to review it :P >>> >>> Ok maybe the second point is not that relevant LOL >>> Just that I am sure that the fix I proposed works well with Spec. >>> And I an pretty sure the other will break it :) >>> >>> I was not aware of another case related to this. >>> It is not flagged Spec nor my name, so there is no way for me to guess it >>> exists. >>> >>> Ben >> > >
Re: [Pharo-dev] Issues 12717 and 12684
On 27 Jan 2014, at 20:08, Sven Van Caekenberghe wrote: > Are the compatible ? > Does one have to come before the other ? > Are they both needed ? I think we should drop > https://pharo.fogbugz.com/f/cases/12717/ReactiveVariable-NewValueHolder and integrate > https://pharo.fogbugz.com/f/cases/12684/NewValueHolder-Enhancements For at least two reasons: - I added hooks for Spec to continue working with the slice I proposed (otherwise no more Spec fix until the release) - I do not have to review it :P Ok maybe the second point is not that relevant LOL Just that I am sure that the fix I proposed works well with Spec. And I an pretty sure the other will break it :) I was not aware of another case related to this. It is not flagged Spec nor my name, so there is no way for me to guess it exists. Ben
Re: [Pharo-dev] StHub (mostly) down ?
This is always returning ‘down’ for Smalltalkhub :) Ben On 25 Jan 2014, at 15:37, Max Leske wrote: > Down: http://www.downforeveryoneorjustme.com/smalltalkhub.com > > > On 25.01.2014, at 19:33, Sven Van Caekenberghe wrote: > >> StHub (mostly) down ? >> > >
Re: [Pharo-dev] asReactiveVariable ????
Do whatever you want, I have no more motivation to discuss this anymore Ben On 24 Jan 2014, at 14:34, Pharo4Stef wrote: > Hi guys, > > I think that we will rename all the asReactiveVariable that got introduced > into their old name asValueHolder. > And we will rename the class too to its old name. > > Why? > > I think that we should not change at the last moment ValueHolder into > ReactiveVariable > even if the name could be better: > > - First there are books around (and not only mine) that use this > vocabulary for decades. > - Second all the Spec tools developed by people right now do not work > in latest 3.0. > - I think that this change does not worth the noise it introduced: all > the future changes of Spec-based tools that > will be using asReactive will not work in Pharo3.0. > > > We are in beta and now we should not change that. > Then I would appreciate that we discuss it before. > Because I would not change that even between versions of Pharo. > > Stef
Re: [Pharo-dev] About doing things late (1 month before release)
On 24 Jan 2014, at 10:53, Marcus Denker wrote: > What will it help? Who will then decide? Why does that person not help > deciding now? Because it requires downloading an image, loading the slices check the diff. If in Lille this can takes few minutes (which is already long), in Chile this is roughly 10 minutes just to have the changes. Ben
Re: [Pharo-dev] problems with RPackage and cie...
Step to reproduce: Open latest Pharo30719. Create a new package with shortcut or menu. Name it ‘AST-Monkey’ (to have a RPackage not a Tag) Go in another package. Select some classes. CMD M + CMD C (and probably with the menu too) (note that the Drag n’ Drop works) Type the name of the package ‘AST-Monkey’ + enter BOUM Might be that you fixed the drag n drop in the PackageTreeNautilusUI but not the move class. Ben On 24 Jan 2014, at 10:23, Esteban Lorenzano wrote: > I would really like a reproducible case… in the form of an image, if no else. > > btw… moose 5.0 images are severely broken in that area, so if you are using > one of them you *will* have problems. > > Esteban > > On 24 Jan 2014, at 13:28, Goubier Thierry wrote: > >> >> >> Le 23/01/2014 18:57, Benjamin Van Ryseghem a écrit : >>> Just that you know I faced it again :( >>> I created a new RPackage, move classes in the newly created RPackage. >>> And when I wanted to commit the code, it was empty. >> >> Have you tried with the old Browser to see if your classes were in the right >> category? >> >> (When I see something suspicious like that happening, I often open the three >> browsers to double check: AltBrowser, Nautilus and Browser). >> >> And I have not seen anything suspicious that I could pinpoint to RPackage so >> far. Small bugs easily corrected, yes. Big totally out of sync, no. >> >> Thierry >> -- >> Thierry Goubier >> CEA list >> Laboratoire des Fondations des Systèmes Temps Réel Embarqués >> 91191 Gif sur Yvette Cedex >> France >> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >> > >
Re: [Pharo-dev] About doing things late (1 month before release)
On 24 Jan 2014, at 10:25, Marcus Denker wrote: > > And I can not be the only person who decides things. I think people have no > idea how tiring it is > to take a decisions like that all the time. > > The tiring thin about integrating is not the integration. It’s the fact that > one has to *decide* something > like that 10 times a day. > Should I say that then maybe we should change the integration process? As already proposed multiple times? Ben
Re: [Pharo-dev] About doing things late (1 month before release)
On 24 Jan 2014, at 10:18, Marcus Denker wrote: > In beta normally we should not change things that require people to change > again code... Then do not integrate them ... Ben
