[Pharo-users] Updating Pharo 2 - Unable to resolve ConfigurationOfFuel

2013-11-03 Thread Bahman Movaqar
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

2013-11-03 Thread kilon alios
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

2013-11-03 Thread Marcus Denker

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

2013-11-03 Thread Sven Van Caekenberghe

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.

2013-11-03 Thread MartinW
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.

2013-11-03 Thread Yuriy Tymchuk
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-03 Thread Sergi Reyner
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.

2013-11-03 Thread Stephan Eggermont
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.

2013-11-03 Thread Yuriy Tymchuk
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.

2013-11-03 Thread Camillo Bruni

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.

2013-11-03 Thread kilon alios
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.

2013-11-03 Thread p...@highoctane.be
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.

2013-11-03 Thread Marcus Denker

 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.

2013-11-03 Thread Benjamin
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.

2013-11-03 Thread Benjamin
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.

2013-11-03 Thread kilon alios
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.

2013-11-03 Thread Yuriy Tymchuk

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.

2013-11-03 Thread nacho
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.

2013-11-03 Thread kilon alios
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.

2013-11-03 Thread Yuriy Tymchuk

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

2013-11-03 Thread Camillo Bruni

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

2013-11-03 Thread Benjamin
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

2013-11-03 Thread Sergi Reyner
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.

2013-11-03 Thread Stéphane Ducasse
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.

2013-11-03 Thread Stéphane Ducasse
+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

2013-11-03 Thread Stéphane Ducasse
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-03 Thread Sergi Reyner
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

2013-11-03 Thread Mariano Martinez Peck
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

2013-11-03 Thread Stéphane Ducasse
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-03 Thread Sergi Reyner
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

2013-11-03 Thread Stéphane Ducasse

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

2013-11-03 Thread Marcus Denker

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

2013-11-03 Thread Marcus Denker

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