Waiting forever on squeaksource (citezen)

I tried to install Citezen-All-onierstrasz.18 from
'http://www.squeaksource.com/Citezen' but after I hit load the hourglass
just sits there (waited several minutes).  I've pulled other packages
successfully from squeaksource, as recently as yesterday.

I'm not sure if there is some problem with squeaksource, or if it is
particular to this package.  The wiki indicates pharo.  I'm in a 3.10
image with some additions, notably magma, and no seaside or pier.

Any ideas what's going on?
Ross

8 November 2009 10:42:48 am

VM: unix - a SmalltalkImage
Image: Squeak3.10.2 [latest update: #7179]

SecurityManager state:
Restricted: false
FileAccess: true
SocketAccess: true
Working Dir /home/ross/recipes
Trusted Dir /home/ross/recipes/secure
Untrusted Dir /home/ross/recipes/My Squeak

[] in Semaphore>>waitTimeoutMSecs: {[self wait]}
        Arguments and temporary variables:
                anInteger: 5000
                d: a Delay

BlockContext>>ensure:
        Receiver: [] in Semaphore>>waitTimeoutMSecs: {[self wait]}
        Arguments and temporary variables:
                aBlock: [] in Semaphore>>waitTimeoutMSecs: {[d unschedule]}
                returnValue: nil
                b: nil
        Receiver's instance variables:
                sender: BlockContext>>ensure:
                pc: 51
                stackp: 1
                nargs: 0
                startpc: 49
                home: Semaphore>>waitTimeoutMSecs:

Semaphore>>waitTimeoutMSecs:
        Receiver: a Semaphore()
        Arguments and temporary variables:
                anInteger: 5000
                d: a Delay
        Receiver's instance variables:
                firstLink: nil
                lastLink: nil
                excessSignals: 1

HTTPSocket(OldSocket)>>waitForDataUntil:
        Receiver: a HTTPSocket[connected]
        Arguments and temporary variables:
                deadline: 79126549
                dataArrived: false
        Receiver's instance variables:
                semaphore: a Semaphore()
                socketHandle: a ByteArray(147 234 227 89 0 0 0 0 72 20 84 8)
                readSemaphore: a Semaphore()
                writeSemaphore: a Semaphore()
                primitiveOnlySupportsOneSemaphore: false
                buffer: nil
                bufferPos: nil
                headerTokens: nil
                headers: nil
                responseCode: nil


--- The full stack ---
[] in Semaphore>>waitTimeoutMSecs: {[self wait]}
BlockContext>>ensure:
Semaphore>>waitTimeoutMSecs:
HTTPSocket(OldSocket)>>waitForDataUntil:
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
HTTPSocket>>getResponseUpTo:ignoring:
[] in HTTPSocket class>>httpGetDocument:args:accept:request: {[sock :=
HTTPSocket new.  sock connectTo: serverAddr port: connectToPort.  (...]}
SmallInteger(Integer)>>timesRepeat:
HTTPSocket class>>httpGetDocument:args:accept:request:
HTTPSocket class>>httpGet:args:accept:request:
HTTPSocket class>>httpGet:args:user:passwd:
MCHttpRepository>>allFileNames
MCHttpRepository(MCFileBasedRepository)>>allFileNamesOrCache
MCHttpRepository(MCFileBasedRepository)>>readableFileNames
MCHttpRepository(MCFileBasedRepository)>>allFileNamesForVersionNamed:
MCHttpRepository(MCFileBasedRepository)>>versionWithInfo:ifAbsent:
MCHttpRepository(MCRepository)>>versionWithInfo:
[] in MCRepositoryGroup>>versionWithInfo:ifNone: {[:ea | (ea
versionWithInfo: aVersionInfo)   ifNotNilDo: [:v | ^ v]]}
[] in MCRepositoryGroup>>repositoriesDo: {[aBlock value: ea]}
BlockContext>>on:do:
[] in MCRepositoryGroup>>repositoriesDo: {[:ea | [aBlock value: ea]  
on: Error   do: []]}
Array(SequenceableCollection)>>do:
MCRepositoryGroup>>repositoriesDo:
MCRepositoryGroup>>versionWithInfo:ifNone:
[] in MCVersionDependency>>resolve {[MCRepositoryGroup default  
versionWithInfo: versionInfo   ifNone: []]}
MCRepositoryGroup>>versionWithInfo:ifNone:
MCVersionDependency>>resolve
MCVersionLoader>>addDependency:
[] in MCVersionLoader>>addVersion: {[:ea | self addDependency: ea]}
Array(SequenceableCollection)>>do:
MCVersionLoader>>addVersion:
MCVersionLoader class>>loadVersion:
MCVersion>>load
[] in MCFileRepositoryInspector(MCVersionInspector)>>load {[self version
load]}
BlockContext>>ensure:
CursorWithMask(Cursor)>>showWhile:
MCFileRepositoryInspector(MCVersionInspector)>>load
MCFileRepositoryInspector>>load
PluggableButtonMorphPlus(PluggableButtonMorph)>>performAction
PluggableButtonMorphPlus>>performAction
[] in PluggableButtonMorphPlus(PluggableButtonMorph)>>mouseUp: {[:m | (m
containsPoint: evt cursorPoint)   ifTrue: [m performAction]]}
Array(SequenceableCollection)>>do:
PluggableButtonMorphPlus(PluggableButtonMorph)>>mouseUp:
PluggableButtonMorphPlus>>mouseUp:
PluggableButtonMorphPlus(Morph)>>handleMouseUp:
MouseButtonEvent>>sentTo:
PluggableButtonMorphPlus(Morph)>>handleEvent:
PluggableButtonMorphPlus(Morph)>>handleFocusEvent:
[] in HandMorph>>sendFocusEvent:to:clear: {[ActiveHand := self.
ActiveEvent := anEvent.  result := focusHolder     han...]}
[] in PasteUpMorph>>becomeActiveDuring: {[aBlock value]}
BlockContext>>on:do:
PasteUpMorph>>becomeActiveDuring:
HandMorph>>sendFocusEvent:to:clear:
HandMorph>>sendEvent:focus:clear:
HandMorph>>sendMouseEvent:
...etc...

El dom, 08-11-2009 a las 10:52 -0800, [hidden email]
escribió:
> I tried to install Citezen-All-onierstrasz.18 from
> 'http://www.squeaksource.com/Citezen' but after I hit load the hourglass
> just sits there (waited several minutes).  I've pulled other packages
> successfully from squeaksource, as recently as yesterday.

Try Ctrl + . to see what process is hanging the image.

>
> I'm not sure if there is some problem with squeaksource, or if it is
> particular to this package.  The wiki indicates pharo.  I'm in a 3.10
> image with some additions, notably magma, and no seaside or pier.

Do you need Squeak for some reason? If not, just use Pharo.
--
Miguel Cobá
http://miguel.leugim.com.mx

On 11/8/09 9:14 PM, "Miguel Enrique Cobá Martinez" <[hidden email]>
wrote:

> Do you need Squeak for some reason? If not, just use Pharo.

This kind of mail UPSET me.

If you wish be lost in the fog of boredom and you only interest is Web, well
go Pharo (or PHP or Perl or Python)

If as me you think Squeak have lots more , stay here.

I don't ask you join us, but please don't fight against us.

Edgar

El lun, 09-11-2009 a las 08:09 -0200, Edgar J. De Cleene escribió:
>
>
> On 11/8/09 9:14 PM, "Miguel Enrique Cobá Martinez" <[hidden email]>
> wrote:
>
> > Do you need Squeak for some reason? If not, just use Pharo.
>
> This kind of mail UPSET me.

Too bad for you then.

>
> If you wish be lost in the fog of boredom and you only interest is Web, well
> go Pharo (or PHP or Perl or Python)

As most of the lately attention to squeak is. Lets be serious, there is
a tiny market for pure Squeak or desktop apps right now, no matter how
good the technology is.

>
> If as me you think Squeak have lots more , stay here.

For academic purposes I agree, in fact it is really wonderful the things
you found on squeak but, squeak isn't the only source of innovation.

- Squeak loudly promotes OODBs like magma but see the current times.
Non-relational and non-object-oriented databases are the way to go for
quite a few applications. No matter how good the OODBs are.

- That you can use the Squeak to teach children all around the world,
marvelous. Really marvelous, but my kids need real food right now and
the webapps are bringing food to my table.

- You like Squeak  a lot, great, I like to have a tool to sell software
or services to people willing to spend a few bucks on them, great for
me.

And no, I didn't say hey, don't use squeak, doesn't work, is bad, it is
the plage. No. I said:

> Do you need Squeak for some reason? If not, just use Pharo.

An honest questions, if he needs squeak then well try to fix the problem
for Squeak. If he doesn't need squeak, then why lose time, use Pharo and
get *the real problem in his hand* solved and go on.

Cheers.


 
>
> I don't ask you join us, but please don't fight against us.

Sorry but you are the one fighting.

>
> Edgar
>
>
>
--
Miguel Cobá
http://miguel.leugim.com.mx

On Sun, 2009-11-08 at 10:52 -0800, [hidden email] wrote:
> I tried to install Citezen-All-onierstrasz.18 from
> 'http://www.squeaksource.com/Citezen' but after I hit load the hourglass
> just sits there (waited several minutes).  I've pulled other packages
> successfully from squeaksource, as recently as yesterday.
For the record, the problem is cleared up now.  I assume the cause was
the hang-up of squeaksource reported by Nicolas.

I prefer to use squeak because getting magma going under pharo has its
own set of challenges--I'm not even sure I ever got it to work.  magma
only recently added pharo support, so things are probably more likely to
go wrong there.  Finally, I'm not crazy about forks and want to help the
mainline stay healthy.

Ross

El mar, 10-11-2009 a las 12:02 -0800, Ross Boylan escribió:
Umm, I haven't had any problem and I am using it daily on production.
What problem do you have to got it work on Pharo?

> magma
> only recently added pharo support, so things are probably more likely to
> go wrong there.  

That is a subjective opinion. As said before I haven't had any problem
with magma on pharo.


> Finally, I'm not crazy about forks and want to help the
> mainline stay healthy.

I prefer to use PharoCore for deployment and not worry about trimming a
squeak image when loading several images on production. The squeak
stable image is to big, and you must update it and then trimming it.
That is not the case with PharoCore. In it I just load the packages I
want and nothing else. Perfect for deployment.

Cheers
PS. to the "against-recommending-pharo" souls, this is not a pharo
advertisement, just I think that Magma is as stable and solid on Pharo
as is on Squeak, no matter its short life.


>
> Ross
>
>
--
Miguel Cobá
http://miguel.leugim.com.mx

Miguel Enrique Cobá Martinez wrote:
> I prefer to use PharoCore for deployment and not worry about trimming a
> squeak image when loading several images on production. The squeak
> stable image is to big, and you must update it and then trimming it.

Out of curiosity, what have you been trimming in the past for your
production deployments?

> PS. to the "against-recommending-pharo" souls, this is not a pharo
> advertisement, just I think that Magma is as stable and solid on Pharo
> as is on Squeak, no matter its short life.

I think it may be helpful to phrase your comments a bit more carefully.
Keep in mind that the split between Pharo and Squeak has left just as
many people wounded here as it has in the Pharo world. There is no need
to rub it in every time you post here. A bit caution is useful since you
don't know the history and the individuals involved.

Cheers,
   - Andreas

On Tue, 2009-11-10 at 14:11 -0600, Miguel Enrique Cobá Martinez wrote:
> Umm, I haven't had any problem and I am using it daily on production.
> What problem do you have to got it work on Pharo?
I don't recall the details, though they are probably in the pharo and
magma archives.
>
> > magma
> > only recently added pharo support, so things are probably more
> likely to
> > go wrong there.  
>
> That is a subjective opinion. As said before I haven't had any problem
> with magma on pharo.
While no one can predict the future, my opinion has some basis in what I
think are generally accepted software principles.  magma has been
developed with squeak and the maintainer has stated that he plans to
continue that way.  The general principle is "software will be more
likely to work well on its native/development platforem."

This morning the magma list had a report that a recent pharo change had
broken magma (slightly), with the maintainer indicating he needs some
help in dealing with such changes now and in the future.


Ross

On Tue, 2009-11-10 at 13:21 -0800, Ross Boylan wrote:
> > Umm, I haven't had any problem and I am using it daily on
> production.
> > What problem do you have to got it work on Pharo?
> I don't recall the details, though they are probably in the pharo and
> magma archives.
In fairness, I should add I've had quite a few problems getting things
working under squeak (again, in the archives).  Quite a few of those
only arise if one wants to run the test suite.  Some of the others just
arose from documentation gaps which have since been fixed.

As a practical matter, I have been jumping back and forth between pharo
and squeak, and various flavors of squeak (3.9 vs 3.10) to get various
things (not just magma).  For seaside, the principle to prefer the
development platform favors pharo.  Of course, for seaside + magma one
has 2 different development platforms, which makes choosing a little
difficult :)

El mar, 10-11-2009 a las 12:22 -0800, Andreas Raab escribió:
> Miguel Enrique Cobá Martinez wrote:
> > I prefer to use PharoCore for deployment and not worry about trimming a
> > squeak image when loading several images on production. The squeak
> > stable image is to big, and you must update it and then trimming it.
>
> Out of curiosity, what have you been trimming in the past for your
> production deployments?

I don't remember exactly but they included sound related ones like
nebraska, tests, squeak map, sunit, a lot of morphic extras and complete
categories that my code didn't use. A lot of trial and test in order to
not break anything.

Fair enough.

>
> Cheers,
>    - Andreas
>
--
Miguel Cobá
http://miguel.leugim.com.mx

2009/11/10 Andreas Raab <[hidden email]>:
+1

i want to see a success for both Squeak and Pharo (!!SERIOUSLY!!). I
don't see much barriers why they could not coexist peacefully and
exchange the ideas. But if we start agitating people, like Miguel
does, there are less chances to have a peaceful coexistance, and maybe
Miguel don't realizing that he does more damage to Pharo by agitating
people to switch on it, than
any potential benefit, because there always other people who
potentially would consider to contribute to Pharo, but don't like the
attitude how people like Miguel treating Squeak.

People choosing the platform to work with for own reasons, lets just
respect their choice.


> Cheers,
>  - Andreas
>
>



--
Best regards,
Igor Stasenko AKA sig.

El mié, 11-11-2009 a las 00:08 +0200, Igor Stasenko escribió:
WTF are you saying.

I am not against Squeak but I also promote Pharo for my own personal
views. But from that to bash squeak there is a big gap.

Regarding the "attitude" you talk about. I put the PS in the reply
because of the reply of Edgar in

http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-November/140726.html

was very loudly about a simple and honest question

So I replied in

http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-November/140732.html


And no, I didn't say hey, don't use squeak, doesn't work, is bad, it is
the plage[sic]. No. I said:

> Do you need Squeak for some reason? If not, just use Pharo.

An honest questions, if he needs squeak then well try to fix the problem
for Squeak. If he doesn't need squeak, then why lose time, use Pharo and
get *the real problem in his hand* solved and go on.

Cheers.


 
>
> I don't ask you join us, but please don't fight against us.

Sorry but you are the one fighting.

>
> Edgar
>
>


So, man don't do this thread more flaming that is already. I have
accepted the Andreas' advice about carefully wording the posts but don't
accuse me of this "attitude how people like Miguel treating Squeak."




>
> People choosing the platform to work with for own reasons, lets just
> respect their choice.
>

Again, I never said that _should_ or _must_ change to Pharo, only asked
if he needed Squeak for some specific reason or package. If not, maybe
he could just use Pharo and continue working in his app/demo/setup
whatever.

Puf! And I am the one with the attitude! Yeah!

--
Miguel Cobá
http://miguel.leugim.com.mx

2009/11/11 Miguel Enrique Cobá Martinez <[hidden email]>:
Wrong. The more correct would be "use Pharo and get another, different
problem at hand".
And its nothing to do with fact that Pharo is better or worse than
Squeak, this is the nature of things, when forks each progressing in
own direction.
>From that perspective your proposal is bad & blatant. That's why i
said - respect people choice.



--
Best regards,
Igor Stasenko AKA sig.

El mié, 11-11-2009 a las 00:52 +0200, Igor Stasenko escribió:

But nobody is forcing him to use Pharo, just that, as in other reply
Torsten said, the Citezen package has been tested on Pharo:

>From the wiki of the Citezen page:

Package organization
Quick pharo install:
Installer ss project: 'Citezen'; install: 'Citezen-Loader'


and the *the real problem in his hand* it appeared, I realize now,
to point to Squeak, but I was refering to the application he was trying to build.
That is what he should focus effort and not in trying to chase the cause of the problem
when trying to load Citezen on Squeak.

So, one more time I didn't bash Squeak just asked if he needed Squeak for something
indispensable to his project so that if not, he could just use Pharo and continue building
his own project.

I will not discuss more this topic.

--
Miguel Cobá
http://miguel.leugim.com.mx

> This morning the magma list had a report that a recent pharo change had
> broken magma (slightly), with the maintainer indicating he needs some
> help in dealing with such changes now and in the future.

I think even with "(slightly)" your words are (slightly) too strong.
:)  Perhaps actually MY words in the original post were too strong
too.

It's just a Monticello informative "warning" Ross, indicating three
extension methods for serializing/materializing the global EventSensor
will not be loaded.

99% of applications would not ever want to try to serialize that, so
it won't be a real problem for them.

Regards,
  Chris

On Wed, 2009-11-11 at 09:54 -0600, Chris Muller wrote: I thought the issue was not that someone would want to serialize a
sensor, but that with the rename it might get persisted as part of an
object graph, with weird results if it ever came back from the database
into, e.g., a different image (or maybe even the same image).

Equivalently, I thought the methods on EventSensor kept it from being
persisted, and that the new InputEventSensor (?) in pharo will lack such
protection.

My understanding may well be incorrect.

Ross