[Pharo-users] Updating Pharo 2 - Unable to resolve ConfigurationOfFuel
Hi all, I just downloaded Pharo 2.0 on a Windows machine, unpacked it, ran it and from the world menu selected System - Software Update but bumped into an exception: stacktrace Error: Unable to resolve ConfigurationOfFuel GoferConfigurationReference(Object)error: GoferConfigurationReference(GoferReference)resolveWith: Goferresolved in Block: [:each | each resolveWith: self] Array(SequenceableCollection)collect: Goferresolved GoferLoadinitializeOn: GoferLoad class(GoferOperation class)on: Goferexecute:do: Goferexecute: Goferload ScriptLoaderupdate20608 UndefinedObjectDoIt Compilerevaluate:in:to:notifying:ifFail:logged: Compiler classevaluate:for:notifying:logged: Compiler classevaluate:for:logged: Compiler classevaluate:logged: DoItDeclarationimport CodeImporterevaluateDeclarations in Block: [:decl | value := decl import] OrderedCollectiondo: CodeImporterevaluateDeclarations CodeImporter classevaluateReadStream: ChangeSet classnewChangesFromStream:named: in Block: [| newStream |... BlockClosureensure: ChangeSet classnewChangesFromStream:named: UpdateStreamerelementaryReadServerUpdates: in Block: [| docQueue docQueueSema |... BlockClosureensure: CursorWithMask(Cursor)showWhile: UpdateStreamerelementaryReadServerUpdates: UpdateStreamerelementaryReadServerUpdates UpdateStreamerupdateFromServer in Block: [self elementaryReadServerUpdates] /stacktrace This is an ablsolutely fresh Pharo instance. Am I doing anything wrong? How can I resolve this? TIA, -- Bahman Movaqar (http://BahmanM.com) ERP Evaluation, Implementation Deployment Consultant PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com) signature.asc Description: OpenPGP digital signature
Re: [Pharo-users] Updating Pharo 2 - Unable to resolve ConfigurationOfFuel
no you dont do anything wrong, unfortunately from what I have been told the update process is broken. Right now the best choices is to download directly from pharo website http://www.pharo-project.org/pharo-download this will get you the latest release from the version you choose there is also Pharo Launcher http://www.smalltalkhub.com/#!/~Pharo/PharoLauncher Pharo Launcher advantages over downloading directly from the pharo website is that it allows you with one click to download specific release and also custom images that contain specific libraries. It also helps you manage your image files, delete them, rename them , etc. I assume that most likely Pharo Launcher will replace the pharo update process but automatically getting the latest release, at some point in the future. In any case getting latest release is a very easy process. On Sun, Nov 3, 2013 at 11:24 AM, Sven Van Caekenberghe s...@stfx.eu wrote: Hi Bahman, Pharo 2.0 is released, if you load the latest version from the website, you should not have to do any system updates. That being said, the bug should not happen. Sven On 03 Nov 2013, at 07:10, Bahman Movaqar bah...@bahmanm.com wrote: Hi all, I just downloaded Pharo 2.0 on a Windows machine, unpacked it, ran it and from the world menu selected System - Software Update but bumped into an exception: stacktrace Error: Unable to resolve ConfigurationOfFuel GoferConfigurationReference(Object)error: GoferConfigurationReference(GoferReference)resolveWith: Goferresolved in Block: [:each | each resolveWith: self] Array(SequenceableCollection)collect: Goferresolved GoferLoadinitializeOn: GoferLoad class(GoferOperation class)on: Goferexecute:do: Goferexecute: Goferload ScriptLoaderupdate20608 UndefinedObjectDoIt Compilerevaluate:in:to:notifying:ifFail:logged: Compiler classevaluate:for:notifying:logged: Compiler classevaluate:for:logged: Compiler classevaluate:logged: DoItDeclarationimport CodeImporterevaluateDeclarations in Block: [:decl | value := decl import] OrderedCollectiondo: CodeImporterevaluateDeclarations CodeImporter classevaluateReadStream: ChangeSet classnewChangesFromStream:named: in Block: [| newStream |... BlockClosureensure: ChangeSet classnewChangesFromStream:named: UpdateStreamerelementaryReadServerUpdates: in Block: [| docQueue docQueueSema |... BlockClosureensure: CursorWithMask(Cursor)showWhile: UpdateStreamerelementaryReadServerUpdates: UpdateStreamerelementaryReadServerUpdates UpdateStreamerupdateFromServer in Block: [self elementaryReadServerUpdates] /stacktrace This is an ablsolutely fresh Pharo instance. Am I doing anything wrong? How can I resolve this? TIA, -- Bahman Movaqar (http://BahmanM.com) ERP Evaluation, Implementation Deployment Consultant PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)
Re: [Pharo-users] Updating Pharo 2 - Unable to resolve ConfigurationOfFuel
On 03 Nov 2013, at 10:54, kilon alios kilon.al...@gmail.com wrote: no you dont do anything wrong, unfortunately from what I have been told the update process is broken. Right now the best choices is to download directly from pharo website The problem is that how images are used is shifting: People used to use an image for a long time, updating the base from time to time while their code was in the image. These days, what people do is to have an automatic (and well defined) process that build a fresh image on - base system is updated - Own code commit So e.g. I never retain images after I finish something. I commit, wait for the build system to tell me everything is green, and I throw the image away. Images are transient things. This in turn means nobody uses updating, and this means that it is not tested. and everything not tested brakes after a while…. (In turn, everything we want to be sure works needs to be tested after every commit, but testing “updating every old version to the newest” is not really testable, anayway…) When we move to an image-bootstrap for the development of Pharo itself (I guess in Pharo4), we should really check what and how (and if) we support updating existing images, or if we declare the image to be something that *always* be the result of a deterministic build process… Marcus
Re: [Pharo-users] Updating Pharo 2 - Unable to resolve ConfigurationOfFuel
On 03 Nov 2013, at 12:37, Marcus Denker marcus.den...@inria.fr wrote: When we move to an image-bootstrap for the development of Pharo itself (I guess in Pharo4), we should really check what and how (and if) we support updating existing images, or if we declare the image to be something that *always* be the result of a deterministic build process… Yes, a base image should be exactly that !
[Pharo-users] I would rather pay for Smalltalkhub than use Github for free.
Just a thought on the discussions about Smalltalkhub beeing down and people would love to use Gibhub instead: I would rather pay for Smalltalkhub than use Github for free. And there is all this talk about building a business with Pharo - why not make a business from Smalltalkhub? The thought of course is that when Smalltalkhub would be a business, it’s makers could spend more time and effort keeping it up and running and adding new features. This may have been quoted a lot but still: The lesson: People are happy to pay for things that work well. Never be afraid to put a price on something. If you pour your heart into something and make it great, sell it. For real money. Even if there are free options, even if the market is flooded with free. People will pay for things they love.“ From: http://37signals.com/svn/posts/2794-how-to-get-good-at-making-money -- View this message in context: http://forum.world.st/I-would-rather-pay-for-Smalltalkhub-than-use-Github-for-free-tp4718690.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] I would rather pay for Smalltalkhub than use Github for free.
Hi. You’re right in general. But for me the main question is: can Monticello work well? This thing was not evolving for years. Something has to be done. Uko On 03 Nov 2013, at 13:22, MartinW w...@fastmail.fm wrote: Just a thought on the discussions about Smalltalkhub beeing down and people would love to use Gibhub instead: I would rather pay for Smalltalkhub than use Github for free. And there is all this talk about building a business with Pharo - why not make a business from Smalltalkhub? The thought of course is that when Smalltalkhub would be a business, it’s makers could spend more time and effort keeping it up and running and adding new features. This may have been quoted a lot but still: The lesson: People are happy to pay for things that work well. Never be afraid to put a price on something. If you pour your heart into something and make it great, sell it. For real money. Even if there are free options, even if the market is flooded with free. People will pay for things they love.“ From: http://37signals.com/svn/posts/2794-how-to-get-good-at-making-money -- View this message in context: http://forum.world.st/I-would-rather-pay-for-Smalltalkhub-than-use-Github-for-free-tp4718690.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] Yet another building a GUI question
2013/11/2 b...@openinworld.com Sergi Reyner wrote: - Tried and somewhat succeeded in building my GUI with Spec, which apparently doesn't know about images. As a new framework, sometimes it is just a use-case that has not been considered or prioritized. If you can describe your situation in detail with a simple script that you would expect to work, sometimes you can be surprised at how fast your needs can be met. Obviously I say sometimes because variable factors are many (problem complexity, other peoples priorities) - but (not to get your hopes up too much) I personally have been surprised at time by the speed of response from the Pharo community. Developers can only see-what-they-see from their own perspective. Users are a great asset to a framework to identify gaps. If you can detail your needs with sample code then I'm sure that would be appreciated. I might even give it a go, even though I am not so intimate with Spec. cheers -ben Something like this: initializeWidgets self instantiateModels: { (#listModel - #ListComposableModel). (#pictureModel - #AlphaImageModel). } I tried to follow how Spec thingies are constructed but somewhere along the chain I lost the trail. Cheers, Sergi
Re: [Pharo-users] I would rather pay for Smalltalkhub than use Github for free.
Kilon wrote I take a look at previous experiments like squeaksource and I find little justification to not support Github. But then I am not against Smalltalkhub or other repos being available to Pharo. The more the merrier. I see some very strong arguments against depending on github: - it is centralized infrastructure, essentially unsuitable for use with a distributed version control system; - it doesn’t support working at the right granularity; - the smalltalk community is too small to have any influence on the directions github is taking. It is a commercial organization that can decide to do something we don’t like at any time. It is free, so we are the product. Just take a look at sourceforge; - we can do much better than github (but don’t have enough time). We should be using a P2P, bittorrent like system for version control. Stephan
Re: [Pharo-users] I would rather pay for Smalltalkhub than use Github for free.
But why? On 03 Nov 2013, at 15:52, Stephan Eggermont step...@stack.nl wrote: Kilon wrote I take a look at previous experiments like squeaksource and I find little justification to not support Github. But then I am not against Smalltalkhub or other repos being available to Pharo. The more the merrier. I see some very strong arguments against depending on github: - it is centralized infrastructure, essentially unsuitable for use with a distributed version control system; It’s now. Git is decentralised. And Guthub helps to use that even more with forks, pull requests, etc. - it doesn’t support working at the right granularity; I don’t get the point. - the smalltalk community is too small to have any influence on the directions github is taking. true It is a commercial organization that can decide to do something we don’t like at any time. It is free, so we are the product. Just take a look at sourceforge; - we can do much better than github (but don’t have enough time). We should be using a P2P, bittorrent like system for version control. I think we should think about that. Monticello bothers me a lot. You have a lot of duplications, no safety for previous versions, etc. I don’t like an idea of snapshots. Storing changes looks much better to me. Stephan Uko
Re: [Pharo-users] I would rather pay for Smalltalkhub than use Github for free.
On 2013-11-03, at 15:52, Stephan Eggermont step...@stack.nl wrote: Kilon wrote I take a look at previous experiments like squeaksource and I find little justification to not support Github. But then I am not against Smalltalkhub or other repos being available to Pharo. The more the merrier. I see some very strong arguments against depending on github: - it is centralized infrastructure, essentially unsuitable for use with a distributed version control system; - it doesn’t support working at the right granularity; - the smalltalk community is too small to have any influence on the directions github is taking. It is a commercial organization that can decide to do something we don’t like at any time. It is free, so we are the product. Just take a look at sourceforge; - we can do much better than github (but don’t have enough time). We should be using a P2P, bittorrent like system for version control. github != git and whether we use github or now does not matter at all. What matters is that we use technology that is robust and that we have a versioning system that works decentralized. All of that is solved by git. With filetree we have the proper granularity (methods) With github we have an awesome website, such as we have an aweseome website with smalltalkhub, execpt that monticello should be modernized. Sadly the community is too small to achieve that, and inventing yet another versioning tool/system won't help on the short run. Maybe, yes someday in the future we can have our own fancy fully object-oriented versioning system, but IMO that is wasted effort, as git/mercurial come very close to something ideal. I am happy to give more insight into git, because I think you have quite a wrong picture about it :) signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Pharo-users] I would rather pay for Smalltalkhub than use Github for free.
You will need to explain because I don't understand what you mean by centralized vs distributed , does not support working at the right granularity. Influence the way Github goes is besides the point at this point since we dont have a better alternative and I will be a great oracle to predict , or not, that we wont have one in the next decade. Unless something extraordinary happens and Pharo goes super popular. Being a commercial application has not stopped tons of open source projects porting to it. But hey what do they know. I am not sure what you mean about sourceforge, I see still loads of open source project using it. The thing I see right now, is that I already use Github with Filetree and Monticello-GIT and it works. Can see the commits I made manually to git and create git commits. The only thing it does not do is push though thats also pretty much a matter of adding the code. So it looks like monticello is already there. It could be polished and sophisticated git interaction be integrated but I think with time we will see those things as well hopefully I can give a helping hand. And if Git is good enough to version control Linux source, I dont see why it would be a big problem to Pharo. But even if it is should not be faster if we make extensions to git via monticello to work around these potential problems instead of doing a huge project from scratch ? I will keep trying Monticello-GIT , if it works as well it seems to work I will probably stick with it. I would love also to extend it when I become familiar with its internals. Big thanks to people behind this. I think being against git is perfectly fine, wanting to trying your own thing is awesome, focusing on pharo specific solution is of course a good thing. But then not wanting to do that and use what is already out there can be as wise. On Sun, Nov 3, 2013 at 4:52 PM, Stephan Eggermont step...@stack.nl wrote: Kilon wrote I take a look at previous experiments like squeaksource and I find little justification to not support Github. But then I am not against Smalltalkhub or other repos being available to Pharo. The more the merrier. I see some very strong arguments against depending on github: - it is centralized infrastructure, essentially unsuitable for use with a distributed version control system; - it doesn’t support working at the right granularity; - the smalltalk community is too small to have any influence on the directions github is taking. It is a commercial organization that can decide to do something we don’t like at any time. It is free, so we are the product. Just take a look at sourceforge; - we can do much better than github (but don’t have enough time). We should be using a P2P, bittorrent like system for version control. Stephan
Re: [Pharo-users] I would rather pay for Smalltalkhub than use Github for free.
Monticello is quite good, especially with Metacello associated to it. I'd like to have the MetacelloToolBox working nicely with FTP repos and will spend a while on that in the coming weeks, but frankly, that's great to use to keep things in sync. I'd pay for STH but for private projects and with the bells and whistles of GitHub (Wiki, issues, teams, non smalltalk files etc).Long story short, GitHub is good also. Maybe consortium members fees could get into have STH supported. Phil
Re: [Pharo-users] I would rather pay for Smalltalkhub than use Github for free.
I always joke that he forgot “The only way to have a future is to finish something” ;-) “One of the sad memories of my life is a visit to the celebrated mathematician and inventor, Mr Babbage. He was far advanced in age, but his mind was still as vigorous as ever. He took me through his work-rooms. In the first room I saw parts of the original Calculating Machine, which had been shown in an incomplete state many years before and had even been put to some use. I asked him about its present form. ‘I have not finished it because in working at it I came on the idea of my Analytical Machine, which would do all that it was capable of doing and much more. Indeed, the idea was so much simpler that it would have taken more work to complete the Calculating Machine than to design and construct the other in its entirety, so I turned my attention to the Analytical Machine.’” “After a few minutes’ talk, we went into the next work-room, where he showed and explained to me the working of the elements of the Analytical Machine. I asked if I could see it. ‘I have never completed it,’ he said, ‘because I hit upon an idea of doing the same thing by a different and far more effective method, and this rendered it useless to proceed on the old lines.’ Then we went into the third room. There lay scattered bits of mechanism, but I saw no trace of any working machine. Very cautiously I approached the subject, and received the dreaded answer, ‘It is not constructed yet, but I am working on it, and it will take less time to construct it altogether than it would have token to complete the Analytical Machine from the stage in which I left it.’ I took leave of the old man with a heavy heart.” – Lord Moulton (and if someone says “but he invented the modern computer: No, he did not. We know about him because Ada Lovelance helped him publishing theoretical results (after removing lots of random ramblings about the evil state of research funding). Babagge is *irrelevant* for today. He was rediscovered later after people re-invented his computer. If he would have finished (or just made sure to delegate it, being so trivial that should have been really easy?) he truly would have changed *everything*. “Sometimes you need to finish that damn trivial calculator” — me Marcus
Re: [Pharo-users] Building a simple UI with Spec. Problem with menus.
Hello and welcome :) On 03 Nov 2013, at 18:36, nacho 0800na...@gmail.com wrote: Hi, this is my first post in the Pharo group. I'm developing a simple Text Editor with some nice features as a way to understand how Spec works. It seems that Spec will be the default UI framework from Pharo 3 onwards, I know it's changing and evolving but I'll take the risk. Good to hear :) It is quite changing now, but should not change a lot starting from now (plus a couple of days waiting for the last changes to be integrated). The problem I'm facing is that I'm lost at trying to add a Save as... option in the menu. As far as I know, there is a bug in TextModel where the menu is hardcoded, and therefor can not be changed. In addition, as you have said, it is currently using directly Morphic menus that is bad. The issue 12051 [1] introduces Spec models for menus. The fix has yet to be integrated. So there are two solutions :) 1) You wait a bit tip this issue is integrated, and the TextModel problem solved (which should be done tonight) 2) You load locally the patches so you can try :) If you wanna do so you need to take the latest image and to merge the slices: - 11920 (this one will give you merge conflicts, you can safely take all the incoming versions) - 12051. - 11819 as soon as it is fixed It seems that Spec is still using the Morphic MenuMorphToggleMenuItemMorph but it's not clear to me hoy to add this item. On the other hand, inspecting the ComposableModel class, it seem that in the future this will be done directly in Spec as suggested by the ComposableModeladdMenuItemsToWindowMenu: This method is to add custom menu entries to the window menu :) Ben But so far that method simply says do nothing. Any help? Thanks in advance Cheers Nacho -- View this message in context: http://forum.world.st/Building-a-simple-UI-with-Spec-Problem-with-menus-tp4718881.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. [1] https://pharo.fogbugz.com/default.asp?12051
Re: [Pharo-users] Building a simple UI with Spec. Problem with menus.
On 03 Nov 2013, at 19:05, b...@openinworld.com wrote: nacho wrote: Hi, this is my first post in the Pharo group. I'm developing a simple Text Editor with some nice features as a way to understand how Spec works. It seems that Spec will be the default UI framework from Pharo 3 onwards, I know it's changing and evolving but I'll take the risk. The problem I'm facing is that I'm lost at trying to add a Save as... option in the menu. It seems that Spec is still using the Morphic MenuMorphToggleMenuItemMorph but it's not clear to me hoy to add this item. On the other hand, inspecting the ComposableModel class, it seem that in the future this will be done directly in Spec as suggested by the ComposableModeladdMenuItemsToWindowMenu: But so far that method simply says do nothing. Any help? Thanks in advance Cheers Nacho Check ComposableModel subclass WindowModel. I believe #addMenuItemsToWindowMenu: is just for the Window Menu (the small downward pointing arrow in the title bar) - so it doesn't apply to other ComposableModel subclasses like ListModel, etc. cheers -ben You believe right :) It is indeed for the Window menu. But it applies to any ComposableModel is the sense that when added to a window, the menu entries will be added. But yo were right in the sense that it does not apply to what I call basic widgets (like ListModel TextModel etc). Ben
Re: [Pharo-users] I would rather pay for Smalltalkhub than use Github for free.
I fail to see how Windows prohibited iPhone from appearing or anything in my quote saying that. They are not even in the same market. Well there is windows mobile and now windows 8 for phones and tablets but both are far from monopoly products. Plus iPhone is not even an OS unless you were referring to iOS. I was talking about desktop's future. For your quote to work it would imply Microsoft having monopoly to anything. Fortunately that is not the case. They are big but nowhere near that big. But if they did, well you would be agreeing right now with me ;) On Sun, Nov 3, 2013 at 8:04 PM, Marcus Denker marcus.den...@inria.frwrote: On 03 Nov 2013, at 18:54, kilon alios kilon.al...@gmail.com wrote: Yeah I cant say I agree with Mr Kay my answer to his quote will be that he is wrong and that the best way to predict the future is to create a monopoly” . Yes, in 2007, the iPhone showed that “We can not do anything because Microsoft” was just wrong. Marcus
Re: [Pharo-users] I would rather pay for Smalltalkhub than use Github for free.
On 03 Nov 2013, at 19:17, Marcus Denker marcus.den...@inria.fr wrote: On 03 Nov 2013, at 19:11, kilon alios kilon.al...@gmail.com wrote: I fail to see how Windows prohibited iPhone from appearing or anything in my quote saying that. They are not even in the same market. Yet, that old market is now in a very bad shape and people talk about the “death of the desktop”. You do not need to be in the same market if you can make the old one obsolete. Marcus I think that we should be passionate about what we are doing. Look at Scala for example. It’s becoming quite popular, and it was developed for 10 years. Pharo still has a lot of time to attract people, but we need to push something new. It’s not java like smalltalk, or something smalltalk-inspired that looks like C. For me Pharo is what had to happen to Smalltalk: evolution. Usually Smalltalk is mentioned with “80” suffix. Pharo is Smalltalk2013. And we can make it really cool, but we should stick to smalltalk philosophy. Having tools, working with objects, etc...
Re: [Pharo-users] Building a simple UI with Spec. Problem with menus.
Thanks for your prompt responses. I guess the wise advise is...wait a little but I seldom follow the wise advice so I will continue to try to solve this ;) I've been trying with ComposableModel#WindowModel with no luck as it seems that though the method is implemented in #WindowModel it seems to be inoperative. cheers Nacho -- View this message in context: http://forum.world.st/Building-a-simple-UI-with-Spec-Problem-with-menus-tp4718881p4718902.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] I would rather pay for Smalltalkhub than use Github for free.
Are those the same people that a decade ago were proclaiming Java dead ? It only takes a walk to TIOBE INDEX to see how much of a threat mobile market is to desktop. http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html I am sure Angry Birds and Candy Crash Saga are substantial opponents to Desktop but I don't see Windows sweating from agony any time soon. On Sun, Nov 3, 2013 at 8:17 PM, Marcus Denker marcus.den...@inria.frwrote: On 03 Nov 2013, at 19:11, kilon alios kilon.al...@gmail.com wrote: I fail to see how Windows prohibited iPhone from appearing or anything in my quote saying that. They are not even in the same market. Yet, that old market is now in a very bad shape and people talk about the “death of the desktop”. You do not need to be in the same market if you can make the old one obsolete. Marcus
Re: [Pharo-users] I would rather pay for Smalltalkhub than use Github for free.
On 03 Nov 2013, at 19:33, kilon alios kilon.al...@gmail.com wrote: Are those the same people that a decade ago were proclaiming Java dead ? It only takes a walk to TIOBE INDEX to see how much of a threat mobile market is to desktop. http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html http://blog.timbunce.org/2008/04/12/tiobe-or-not-tiobe-lies-damned-lies-and-statistics/ I am sure Angry Birds and Candy Crash Saga are substantial opponents to Desktop but I don't see Windows sweating from agony any time soon. On Sun, Nov 3, 2013 at 8:17 PM, Marcus Denker marcus.den...@inria.fr wrote: On 03 Nov 2013, at 19:11, kilon alios kilon.al...@gmail.com wrote: I fail to see how Windows prohibited iPhone from appearing or anything in my quote saying that. They are not even in the same market. Yet, that old market is now in a very bad shape and people talk about the “death of the desktop”. You do not need to be in the same market if you can make the old one obsolete. Marcus
Re: [Pharo-users] [Pharo-dev] moving moose to pharo 3.0
On 2013-11-03, at 21:11, Tudor Girba tu...@tudorgirba.com wrote: Hi, We essentially finished moving Moose to Pharo 3.0 (we still have 6 yellow tests but they needed attention anyway). It took about 4 people looking into issues for a total probably around 2 man-days of effort. The largest impediment was actually SmalltalkHub being down for one day :). What posed problems: - RB visitor now has correct visit* methods instead of accept* methods. The deprecation messages helped quite a bit. This meant (1) that we had to rename in our visitors the methods, and (2) that we had to change the old accept* messages. - RB nodes do not answer to #isLiteral anymore. Instead, they answer correctly to #isLiteralNode so that to avoid confusion with Object#isLiteral. This is good, and this meant that we had to hunt all #isLiteral usages in Moose. - Categories are no longer mapped on RPackages through 1-to-1. This is also good because it is an important step in Pharo. Although originally we said we want to keep 1-to-1, this is probably a better solution now. For Moose, this meant that some of our older tests setup had to be modified a bit to rely on RPackage only. - Some Morphs rely now on Announcements, and this had a little impact on the assumptions we make when we suspend announcements (to avoid infinite loops) that are being sent between Morphic and Glamour. We fixed this in Glamour. - In FileSystem #ensureDirectory was renamed to #ensureCreateDirectory without a deprecation. For this one, we should add a deprecation for the old method. opened an issue for that: https://pharo.fogbugz.com/f/cases/12062/ensureDirectory-and-ensureFile-should-be-readded-with-a-deprecation-message - flatCollect had a conflicting behavior in Pharo. We are now integrating the Moose version so that it returns the same species. - The new SpecDebugger expects the registered Inspector to be based on Spec, and this causes problems with the GTInspector. This problem still has to be fixed in Pharo. All in all, we encountered no significant problems and the problems we faced came from deep into Pharo. So, if your code is not relying directly on RB, RPackage or the Debugger, you are likely to have a smooth transition. Cheers, Doru -- www.tudorgirba.com Every thing has its own flow signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Pharo-users] Yet another building a GUI question
I think I missed the beginning of this thread :) So my question is what do you want to do ? :) I tried your ImageSpecTest, and after a minor fix, it opens :) But expect displaying an ImageMorph, it is not really usable :) Ben On 03 Nov 2013, at 21:37, Sergi Reyner sergi.rey...@gmail.com wrote: 2013/11/3 Sergi Reyner sergi.rey...@gmail.com Something like this: initializeWidgets self instantiateModels: { (#listModel - #ListComposableModel). (#pictureModel - #AlphaImageModel). } I gave it another try, and after a few attempts I managed to put together a working example of what I meant, in Pharo 3.0. I attach the .mcz file. Cheers, Sergi Raytests-SergiReyner.1.mcz
Re: [Pharo-users] Yet another building a GUI question
El 03/11/2013 21:45, Benjamin benjamin.vanryseghem.ph...@gmail.com escribió: I think I missed the beginning of this thread :) So my question is what do you want to do ? :) I want to have a way to get an AlphaImageMorph linked to a ValueHolder(?) holding a Form(?), and having it update automatically, for example in response to selecting an item from a list. Cheers, Sergi
Re: [Pharo-users] Building a simple UI with Spec. Problem with menus.
Hi I will integrate some fixes now. Stef Hello and welcome :) On 03 Nov 2013, at 18:36, nacho 0800na...@gmail.com wrote: Hi, this is my first post in the Pharo group. I'm developing a simple Text Editor with some nice features as a way to understand how Spec works. It seems that Spec will be the default UI framework from Pharo 3 onwards, I know it's changing and evolving but I'll take the risk. Good to hear :) It is quite changing now, but should not change a lot starting from now (plus a couple of days waiting for the last changes to be integrated). The problem I'm facing is that I'm lost at trying to add a Save as... option in the menu. As far as I know, there is a bug in TextModel where the menu is hardcoded, and therefor can not be changed. In addition, as you have said, it is currently using directly Morphic menus that is bad. The issue 12051 [1] introduces Spec models for menus. The fix has yet to be integrated. So there are two solutions :) 1) You wait a bit tip this issue is integrated, and the TextModel problem solved (which should be done tonight) 2) You load locally the patches so you can try :) If you wanna do so you need to take the latest image and to merge the slices: - 11920 (this one will give you merge conflicts, you can safely take all the incoming versions) - 12051. - 11819 as soon as it is fixed It seems that Spec is still using the Morphic MenuMorphToggleMenuItemMorph but it's not clear to me hoy to add this item. On the other hand, inspecting the ComposableModel class, it seem that in the future this will be done directly in Spec as suggested by the ComposableModeladdMenuItemsToWindowMenu: This method is to add custom menu entries to the window menu :) Ben But so far that method simply says do nothing. Any help? Thanks in advance Cheers Nacho -- View this message in context: http://forum.world.st/Building-a-simple-UI-with-Spec-Problem-with-menus-tp4718881.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. [1] https://pharo.fogbugz.com/default.asp?12051
Re: [Pharo-users] I would rather pay for Smalltalkhub than use Github for free.
+1 Pharo should be Pharo :) And we should all push in that direction - minimal core - sweet integration with the rest of the world - objects - cool libraries I think that we should be passionate about what we are doing. Look at Scala for example. It’s becoming quite popular, and it was developed for 10 years. Pharo still has a lot of time to attract people, but we need to push something new. It’s not java like smalltalk, or something smalltalk-inspired that looks like C. For me Pharo is what had to happen to Smalltalk: evolution. Usually Smalltalk is mentioned with “80” suffix. Pharo is Smalltalk2013. And we can make it really cool, but we should stick to smalltalk philosophy. Having tools, working with objects, etc...
Re: [Pharo-users] Yet another building a GUI question
Sergi could you sign the Pharo license agreement and send it to us (scanned for example)? Stef On Nov 3, 2013, at 11:10 PM, Sergi Reyner sergi.rey...@gmail.com wrote: El 03/11/2013 21:45, Benjamin benjamin.vanryseghem.ph...@gmail.com escribió: I think I missed the beginning of this thread :) So my question is what do you want to do ? :) I want to have a way to get an AlphaImageMorph linked to a ValueHolder(?) holding a Form(?), and having it update automatically, for example in response to selecting an item from a list. Cheers, Sergi
Re: [Pharo-users] Yet another building a GUI question
Sent to your mail, Stef! 2013/11/3 Stéphane Ducasse stephane.duca...@inria.fr Sergi could you sign the Pharo license agreement and send it to us (scanned for example)? Stef On Nov 3, 2013, at 11:10 PM, Sergi Reyner sergi.rey...@gmail.com wrote: El 03/11/2013 21:45, Benjamin benjamin.vanryseghem.ph...@gmail.com escribió: I think I missed the beginning of this thread :) So my question is what do you want to do ? :) I want to have a way to get an AlphaImageMorph linked to a ValueHolder(?) holding a Form(?), and having it update automatically, for example in response to selecting an item from a list. Cheers, Sergi
Re: [Pharo-users] Updating Pharo 2 - Unable to resolve ConfigurationOfFuel
Bahman, Hi, Fuel was moved some time ago from SS3 to SmalltalkHub. Could it be that it was searching ConfigurationOfFuel in SS3? On Sun, Nov 3, 2013 at 3:10 AM, Bahman Movaqar bah...@bahmanm.com wrote: Hi all, I just downloaded Pharo 2.0 on a Windows machine, unpacked it, ran it and from the world menu selected System - Software Update but bumped into an exception: stacktrace Error: Unable to resolve ConfigurationOfFuel GoferConfigurationReference(Object)error: GoferConfigurationReference(GoferReference)resolveWith: Goferresolved in Block: [:each | each resolveWith: self] Array(SequenceableCollection)collect: Goferresolved GoferLoadinitializeOn: GoferLoad class(GoferOperation class)on: Goferexecute:do: Goferexecute: Goferload ScriptLoaderupdate20608 UndefinedObjectDoIt Compilerevaluate:in:to:notifying:ifFail:logged: Compiler classevaluate:for:notifying:logged: Compiler classevaluate:for:logged: Compiler classevaluate:logged: DoItDeclarationimport CodeImporterevaluateDeclarations in Block: [:decl | value := decl import] OrderedCollectiondo: CodeImporterevaluateDeclarations CodeImporter classevaluateReadStream: ChangeSet classnewChangesFromStream:named: in Block: [| newStream |... BlockClosureensure: ChangeSet classnewChangesFromStream:named: UpdateStreamerelementaryReadServerUpdates: in Block: [| docQueue docQueueSema |... BlockClosureensure: CursorWithMask(Cursor)showWhile: UpdateStreamerelementaryReadServerUpdates: UpdateStreamerelementaryReadServerUpdates UpdateStreamerupdateFromServer in Block: [self elementaryReadServerUpdates] /stacktrace This is an ablsolutely fresh Pharo instance. Am I doing anything wrong? How can I resolve this? TIA, -- Bahman Movaqar (http://BahmanM.com) ERP Evaluation, Implementation Deployment Consultant PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com) -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-users] Yet another building a GUI question
tx and archived! And your enh is in the new integration :) On Nov 4, 2013, at 12:56 AM, Sergi Reyner sergi.rey...@gmail.com wrote: Sent to your mail, Stef! 2013/11/3 Stéphane Ducasse stephane.duca...@inria.fr Sergi could you sign the Pharo license agreement and send it to us (scanned for example)? Stef On Nov 3, 2013, at 11:10 PM, Sergi Reyner sergi.rey...@gmail.com wrote: El 03/11/2013 21:45, Benjamin benjamin.vanryseghem.ph...@gmail.com escribió: I think I missed the beginning of this thread :) So my question is what do you want to do ? :) I want to have a way to get an AlphaImageMorph linked to a ValueHolder(?) holding a Form(?), and having it update automatically, for example in response to selecting an item from a list. Cheers, Sergi
Re: [Pharo-users] Yet another building a GUI question
2013/11/4 Stéphane Ducasse stephane.duca...@inria.fr tx and archived! And your enh is in the new integration :) Yay! Scratching an itch and contributing something feels great :)
Re: [Pharo-users] Yet another building a GUI question
On Nov 4, 2013, at 2:37 AM, Sergi Reyner sergi.rey...@gmail.com wrote: 2013/11/4 Stéphane Ducasse stephane.duca...@inria.fr tx and archived! And your enh is in the new integration :) Yay! Scratching an itch and contributing something feels great :) :) Yes pay attention when you start to like that you learn and lot and you start to be addict :) Stef
Re: [Pharo-users] Updating Pharo 2 - Unable to resolve ConfigurationOfFuel
On 04 Nov 2013, at 00:01, Stéphane Ducasse stephane.duca...@inria.fr wrote: But marcus we are doing update all the time because this is the way we push new updates daily. So I do not understand why this would be different? It happens due to strange things: updates that access the web and URLs change, for example. Or in the past one problem was that it could overload squeak-source to load for hours and hours packages… And it takes quite some care to keep it going: when *really* bad things happen, we now (once or twice in a year) upload a fixed image that is than taken as the base. If you want to support “take pharo2 and update it to pharo3”, (or even, take Pharo3 half a year ago…), then we need to put *a huge* (very huge) effort into making sure that we never ever upload a hand-fixed image. This is a lot of work. And in addition, even that does not guarantee anything: you would need to actually test it… no you dont do anything wrong, unfortunately from what I have been told the update process is broken. Right now the best choices is to download directly from pharo website The problem is that how images are used is shifting: People used to use an image for a long time, updating the base from time to time while their code was in the image. These days, what people do is to have an automatic (and well defined) process that build a fresh image on - base system is updated - Own code commit So e.g. I never retain images after I finish something. I commit, wait for the build system to tell me everything is green, and I throw the image away. Images are transient things. This in turn means nobody uses updating, and this means that it is not tested. and everything not tested brakes after a while…. (In turn, everything we want to be sure works needs to be tested after every commit, but testing “updating every old version to the newest” is not really testable, anayway…) When we move to an image-bootstrap for the development of Pharo itself (I guess in Pharo4), we should really check what and how (and if) we support updating existing images, or if we declare the image to be something that *always* be the result of a deterministic build process… Marcus
Re: [Pharo-users] Updating Pharo 2 - Unable to resolve ConfigurationOfFuel
On 04 Nov 2013, at 08:26, Marcus Denker marcus.den...@inria.fr wrote: On 04 Nov 2013, at 00:01, Stéphane Ducasse stephane.duca...@inria.fr wrote: But marcus we are doing update all the time because this is the way we push new updates daily. So I do not understand why this would be different? It happens due to strange things: updates that access the web and URLs change, for example. Or in the past one problem was that it could overload squeak-source to load for hours and hours packages… And it takes quite some care to keep it going: when *really* bad things happen, we now (once or twice in a year) upload a fixed image that is than taken as the base. If you want to support “take pharo2 and update it to pharo3”, (or even, take Pharo3 half a year ago…), then we need to put *a huge* (very huge) effort into making sure that we never ever upload a hand-fixed image. This is a lot of work. And in addition, even that does not guarantee anything: you would need to actually test it… So in the end, when we get the the bootstrap into Pharo4, this would even mean that keeping an incremental updater would be completely additional work. Like they do with Chrome… I am sure one could generate the diff automatically and detect the cases when it does not work (and tell the user). Would be an interesting research project. Marcus