Squeak-dev December 2012

squeak-dev@lists.squeakfoundation.org

58 participants
216 discussions

Smalltalk unloadAllKnownPackages (was Re: [squeak-dev] The Inbox: GetText-edc.26.mcz)
by H. Hirzel 28 Dec '12

28 Dec '12

On 12/21/12, Edgar J. De Cleene <edgardec2005(a)gmail.com> wrote: > > > > On 12/21/12 5:40 PM, "H. Hirzel" <hannes.hirzel(a)gmail.com> wrote: > >> I loaded your fix from the inbox >> >> GetText-edc.27.mcz >> >> (Note: version 27 not 26 as the subject line indicates) >> >> >> TEST >> >> Smalltalk unloadAllKnownPackages >> >> still does not run through cleanly. >> >> >> >> RESULT >> See attachment >> >> An emergency debugger comes up. >> >> >> .... > > Ok, I unload last Squeak and re test tomorrow. > > Edgar Hello Edgar, I just saw your proposal for a SqueakCore in another thread with some change sets related to version 3.11 Are there any news from your side on an updated (i.e. working) #unloadAllKnownPackages method for the 4.4-12324 version? --Hannes

5 7

FileTree is now in The Catalog
by Chris Muller 28 Dec '12

28 Dec '12

Thanks Hannes, I've documented this in the catalog under the (head) version and also this script to preserve original versions for Squeak 4.4. There are now 22 packages available in the 4.4 app-store! Installer ss3 project: 'FileTree' ; install: 'MonticelloFileTree-Core.squeak43-dkh.90' ; install: 'MonticelloFileTree-FileDirectory-Utilities.squeak43-dkh.12'. On Fri, Dec 28, 2012 at 11:47 AM, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > On 12/20/12, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: >> I hear the new filesystem might do just that. I dont know I am new to all >> this. >> >> But I dont believe integrating github with squeak or pharo is that hard >> anyway. >> >> I am already working with file outs , tedious but not that hard. > > FileTree now nicely loads into Squeak 4.4, I just tested it yesterday. > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2012-December/167275… > > Besides Monticello a means for moving packages around between > different distributions. > > --Hannes > > And if I >> cannot find an existing solution >> that makes me happy , I am more than willing to implement my own library for >> integrating github inside pharo. >> >> Hopefully it will work for squeak too. >> >> >> I was working with emacs for python and magit was great. >> >> Where there is a will there is a way, >> >> >> >> ________________________________ >> From: Frank Shearar <frank.shearar(a)gmail.com> >> To: dimitris chloupis <thekilon(a)yahoo.co.uk>; The general-purpose Squeak >> developers list <squeak-dev(a)lists.squeakfoundation.org> >> Sent: Friday, 21 December 2012, 0:16 >> Subject: Re: [squeak-dev] Squeaksource, Squeak and Pharo.. >> >> Just a note: github does not replace SM. It does not replace rubygems. >> It's a fantastic tool for versioning source control. >> >> I have a toolbox. It has a hammer AND a screwdriver. >> >> frank >> >> On 20 December 2012 22:15, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: >>> SqueakMap is dead, SqueakSource dead, later SmalltalkHub will be dead. >>> >>> I am coming from pharo by the way, I am new with smalltalk, I was a python >>> developer. >>> And I love squeak too. >>> >>> I dont understand why every smalltalk problem should be solved by >>> smalltalk. >>> >>> Github is a great community , already has gathered tons of ruby and python >>> projects, js and many more. >>> >>> I think its a great candidate for smalltalk, no offense intended but >>> definitely better that what SmalltalkHub can offer. >>> >>> I want to embrace at times all these smalltalk technologies, but is hard >>> to >>> abandon Gihub that I have used for my projects and support the smalltalk >>> solutions instead. >>> >>> I dont want to downgrade the hard work of good people, but its hard to >>> compete with products that are designed full time by big teams and matured >>> through thousands of use cases. >>> >>> My vote goes to Github. >>> >>> ________________________________ >>> From: Göran Krampe <goran(a)krampe.se> >>> To: The general-purpose Squeak developers list >>> <squeak-dev(a)lists.squeakfoundation.org> >>> Sent: Thursday, 20 December 2012, 23:14 >>> Subject: Re: [squeak-dev] Squeaksource, Squeak and Pharo.. >>> >>> Hi folks! >>> >>> As the author of SqueakMap, long time Squeaker (and nowadays both Squeaker >>> and Pharooner) and also involved in some other related projects >>> (SmalltalkHub and more) my view might be of some interest. >>> >>> First of all, Angel compares with the rest of the world - but we have both >>> historic and technical differences at play. Some things worth noting: >>> >>> - SqueakMap was indeed started out as a generic package *catalog*. It is >>> not >>> a SCM tool. It was format agnostic from the very beginning. >>> >>> - Monticello and SqueakSource came from Avi. Superb tools but when >>> Squeaksource came I quickly warned the community that it would deminish >>> SqueakMap because it overlapped and "took over" several "catalog" aspects. >>> I >>> was right unfortunately, but at the same time SS was great and has served >>> us >>> very well in its own right. >>> >>> - Noone has really taken SM and moved it forward. I also don't have that >>> amount of free time anymore. >>> >>> - SqueakMap is dead. Face it. :) It is not the future IMHO. >>> >>> - Monticello and Metacello are the de facto standard these days for SCM >>> and >>> package loading. Metacello took the whole dependencies/tagging/releases >>> issue and simply rode on MC to solve it. I have felt it looks overly >>> complex >>> but it's mostly some line noise - it is not that complicated. >>> >>> - This also means that for a very, very long time package management and >>> source code management will be forever "intertwined" in the Smalltalk >>> world. >>> Personally I say - fine! Again, let's just embrace it and go. >>> >>> - The advantage is that Metacello "configurations" is "just code" and can >>> offer functionality totally independent of the hosting platform for MC. So >>> it doesn't matter if you load a Metacello configuration from a website, >>> from >>> SS or SS3 or Smalltalkhub - it all works the same! >>> >>> - Monticello AND Metacello are meant to work in Squeak too. I haven't >>> tried, >>> but I presume Metacello works or is very close to working? >>> >>> - Pharo is betting hard on Smalltalkhub. It is a really nice system AND >>> there is also an image side client tool brewing for it! This means the >>> equivalence of the SqueakMap Package Loader will be easy to build in >>> Squeak >>> for Smalltalkhub. >>> >>> >>> So my advice would be: >>> >>> 1. Keep SqueakMap on oxygen for a little while longer while we get ready >>> to >>> ditch it. Really. >>> >>> 2. Bet hard on Monticello (we already do, right?) and Metacello for >>> Squeak. >>> Make sure they work. Embrace Metacello even if it does look a bit complex >>> to >>> begin with. There are lots of articles, tutorials and tons of examples to >>> just copy from. I have written two configurations these last two days and >>> "the shit works". Good work Dale! :) >>> >>> 3. Get involved in Smalltalkhub and help out making it work fine for >>> Squeak, >>> note the name - *Smalltalk* hub. It's not Pharohub! Don't set up your own >>> unless for some odd reason Pharo makes it uninhabitable for Squeak and >>> turns >>> it into "Pharohub". >>> >>> Note that Smalltalkhub is "just" a new SS, but much more solid >>> architecture, >>> really snazzy modern web UI, offering githubish features and bloody hell, >>> I >>> mean, it can show diffs right there in the browser! >>> >>> Smalltalkhub also has a really cool architecture so the coding fun is >>> rated >>> A++, Nicolas is busy as a bee making it better, better. I think it should >>> be >>> seen as a unifying playground and Metacello as the "glue" that makes it >>> possible to have projects tailored for both Squeak and Pharo. It has many >>> functions for EXACTLY that. >>> >>> Either way, I am putting my efforts right there. IMHO the Squeak community >>> should do so too. If the Squeak community can ride a bit on the momentum >>> in >>> Pharo - there is really no reason not to. >>> >>> regards, Göran >>> >>> >>> >>> >>> >>> >

1 0

squeak.org/source.squeak.org back up
by Chris Cunnington 28 Dec '12

28 Dec '12

All systems back up. On 2012-12-28 10:53 AM, Chris Muller wrote: > (Moved to box-admins). > > Are you sure that's the right action to take? If you are, then great. > But Ken is usually very responsive, we should give him a bit more > than an hour unless you are 100% certain rebooting will get everything > back up and running. > > Right now it looks like user 'website' is active (~30% cpu). It and > 'wiki' both consuming 1GB RAM, that seems high.. > > No. I couldn't be sure. But I had never done it before, so I wanted to try it. It worked. Curiosity propels me in these situations. "I gots to know." http://www.youtube.com/watch?v=H7YKbxmrFbk Chris

3 2

Release candidate Squeak4.4-12320 ready
by Frank Shearar 28 Dec '12

28 Dec '12

* http://ftp.squeak.org/4.4/Squeak4.4-12320.tgz * http://ftp.squeak.org/4.4/Squeak4.4-12320.zip This should fix the MC failing tests. Thanks, Colin! frank

24 75

OpenCroquet
by David Faught 28 Dec '12

28 Dec '12

Thought I saw some discussion of this a while back. Just a few links: http://www.opencroquet.org/ which begat http://www.opencobalt.org/home and http://code.google.com/p/openqwaq/ which is the uncle? of http://virtualworldframework.com/ Nikolay Suslov also had a very nice version which I don't have a link for right now.

2 1

squeak.org/source.squeak.org look down
by Chris Cunnington 28 Dec '12

28 Dec '12

It appears squeak.org and other sites (i.e. archive page for Squeak-dev) are hung/down. I intended to reboot the server with "shutdown -r now" in a little less than an hour. I'm leaving a window so that if somebody has a more appropriate procedure, then they can take over. It's 10:12am here and I intend to reboot at 11am. That's my plan. If that sounds like a bad idea, let me know before then. Chris

1 0

Daily Commit Log
by commits＠source.squeak.org 28 Dec '12

28 Dec '12

Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours: http://lists.squeakfoundation.org/pipermail/packages/2012-December/005603.h… Name: Morphic-dtl.633 Ancestors: Morphic-fbs.632 Fix for: Project current chooseNaturalLanguage ==> DNU =============================================

1 0

who is "eld"?
by Chris Muller 27 Dec '12

27 Dec '12

Connectors-eld.199.mcz in the Connectors repository on SqueakSource has removed NCAAConnectorMorph entirely without regard for its references, and without any description in the change log. Unless eld will come forward to fix and/or explain this, I will remove Connectors-eld.199.mcz from that project. Have a nice day.

1 0

need help from the experts
by Chris Muller 27 Dec '12

27 Dec '12

With Eliot's latest Cog things are really rocking! But I am still having one issue which seems to be related to a Cog code-generation / timing issue. It relates to a hack that dynamically creates a subclass of a domain class to generate overrides of all of its methods that potentially change the state of the object (e.g., a write-barrier). In addition to the overriding methods, it also must generate one accessor method which is used to refer to a Session object, so that the overriding methods can notify it if, in fact, an inst-var changed. When I generate the subclass, I _cannot_ add any new inst-vars to hold the Session (because primChangeClassTo: requires the same physical shape). So, to make the hack work at all, first I compile the following method to establish slots for a couple of literals: myDomainSubclass compileSilently: 'writeBarrier ^ Object first' classified: 'accessing'. Then slap in the Session object I want into the second slot: (myDomainSubclass methodDictionary at: #writeBarrier) literalAt: 2 put: #Object -> (WeakArray with: theSession) Voila! theSession has now been hacked into the CM at literal 2. "Object" in the code now refers to the WeakArray holding my Session rather than the Object class. I wouldn't do this at all if it wasn't for the 3X improvement in commit performance. However, about once or twice a day, I encounter a debugger which indicates, by the accessing attempt, it thinks that literal 2 is an Integer or a Character. Most of the time simply printing "self writeBarrier" right there in the debugger produces the correct answer (the Session object) -- as if Cog suddenly "caught up" with it. Any suggestions are greatly appreciated, thank you!

2 3

The Trunk: Morphic-dtl.633.mcz
by commits＠source.squeak.org 27 Dec '12

27 Dec '12

David T. Lewis uploaded a new version of Morphic to project The Trunk: http://source.squeak.org/trunk/Morphic-dtl.633.mcz ==================== Summary ==================== Name: Morphic-dtl.633 Author: dtl Time: 27 December 2012, 3:09:21.232 pm UUID: fa1e9d6c-e960-448e-ac9d-befb92b80e94 Ancestors: Morphic-fbs.632 Fix for: Project current chooseNaturalLanguage ==> DNU =============== Diff against Morphic-fbs.632 =============== Item was changed: ----- Method: MorphicProject>>chooseNaturalLanguage (in category 'language') ----- chooseNaturalLanguage "Put up a menu allowing the user to choose the natural language for the project" | aMenu availableLanguages | aMenu := MenuMorph new defaultTarget: self. aMenu addTitle: 'choose language' translated. aMenu lastItem setBalloonText: 'This controls the human language in which tiles should be viewed. It is potentially extensible to be a true localization mechanism, but initially it only works in the classic tile scripting system. Each project has its own private language choice' translated. Preferences noviceMode ifFalse:[aMenu addStayUpItem]. + availableLanguages := InternalTranslator availableLanguageLocaleIDs - availableLanguages := NaturalLanguageTranslator availableLanguageLocaleIDs asSortedCollection:[:x :y | x displayName < y displayName]. availableLanguages do: [:localeID | aMenu addUpdating: #stringForLanguageNameIs: target: Locale selector: #switchAndInstallFontToID: argumentList: {localeID}]. aMenu popUpInWorld "Project current chooseNaturalLanguage"!

1 0

← Newer
1
2
3
4
5
6
7
8
...
22
Older →

Jump to page: