Squeak-dev January 2012

squeak-dev@lists.squeakfoundation.org

65 participants
121 discussions

Re: [squeak-dev] The Trunk: Kernel-cmm.667.mcz
by Eliot Miranda 31 Jan '12

31 Jan '12

bummer. I really enjoyed Kernel-ul.666 ;) On Sat, Jan 28, 2012 at 2:37 PM, <commits(a)source.squeak.org> wrote: > Chris Muller uploaded a new version of Kernel to project The Trunk: > http://source.squeak.org/trunk/Kernel-cmm.667.mcz > > ==================== Summary ==================== > > Name: Kernel-cmm.667 > Author: cmm > Time: 28 January 2012, 4:37:01.086 pm > UUID: 40c83fd8-7462-4d3e-807e-ead52745f4eb > Ancestors: Kernel-ul.666 > > Fix copying a Stopwatch. > > =============== Diff against Kernel-ul.666 =============== > > Item was added: > + ----- Method: Stopwatch>>postCopy (in category 'copying') ----- > + postCopy > + super postCopy. > + timespans := timespans copy! > > > -- best, Eliot

2 1

The Trunk: XML-Parser-ael.35.mcz
by commits＠source.squeak.org 31 Jan '12

31 Jan '12

Bert Freudenberg uploaded a new version of XML-Parser to project The Trunk: http://source.squeak.org/trunk/XML-Parser-ael.35.mcz ==================== Summary ==================== Name: XML-Parser-ael.35 Author: ael Time: 22 December 2011, 10:10:20.73 pm UUID: 0d95528e-6e3c-0b48-9c2f-081e5a07ce52 Ancestors: XML-Parser-bf.34 Fix needed to make removeElement: work in subclass XMLElement =============== Diff against XML-Parser-bf.34 =============== Item was changed: ----- Method: XMLNodeWithElements>>removeElement: (in category 'accessing') ----- removeElement: element "Used to purge certain elements from a document after parsing." + self elementsAndContents remove: element ifAbsent: []! - self elements remove: element ifAbsent: []!

1 0

The Trunk: Kernel-eem.668.mcz
by commits＠source.squeak.org 31 Jan '12

31 Jan '12

Eliot Miranda uploaded a new version of Kernel to project The Trunk: http://source.squeak.org/trunk/Kernel-eem.668.mcz ==================== Summary ==================== Name: Kernel-eem.668 Author: eem Time: 30 January 2012, 4:07:10.324 pm UUID: 6d7c03fa-7e34-49ee-af59-08c26564f9ef Ancestors: Kernel-cmm.667 Rip out the "prevent me debugging myself" primitive 19 from ContextPart>doPrimitive:method:receiver:args:. =============== Diff against Kernel-cmm.667 =============== Item was changed: ----- Method: ContextPart>>doPrimitive:method:receiver:args: (in category 'private') ----- doPrimitive: primitiveIndex method: meth receiver: receiver args: arguments "Simulate a primitive method whose index is primitiveIndex. The simulated receiver and arguments are given as arguments to this message. + If successful, push result and return resuming context, else ^ PrimitiveFailToken. + Any primitive which provokes execution needs to be intercepted and simulated - Any primitive which provikes execution needs to be intercepted and simulated to avoid execution running away." | value | + "Judicious use of primitive 19 (a null primitive that doesn't do anything) prevents + the debugger from entering various run-away activities such as spawning a new + process, etc. Injudicious use results in the debugger not being able to debug + interesting code, such as the debugger itself. hence use primtiive 19 with care :-)" + "SystemNavigation new browseAllSelect: [:m| m primitive = 19]" + primitiveIndex = 19 ifTrue: - <primitive: 19> "Simulation guard" - "If successful, push result and return resuming context, - else ^ PrimitiveFailToken" - (primitiveIndex = 19) ifTrue: [ToolSet debugContext: self label:'Code simulation error' contents: nil]. "ContextPart>>blockCopy:; simulated to get startpc right" (primitiveIndex = 80 and: [receiver isKindOf: ContextPart]) ifTrue: [^self push: ((BlockContext newForMethod: receiver method) home: receiver home startpc: pc + 2 nargs: (arguments at: 1))]. (primitiveIndex = 81 and: [receiver isMemberOf: BlockContext]) "BlockContext>>value[:value:...]" ifTrue: [^receiver pushArgs: arguments from: self]. (primitiveIndex = 82 and: [receiver isMemberOf: BlockContext]) "BlockContext>>valueWithArguments:" ifTrue: [^receiver pushArgs: arguments first from: self]. primitiveIndex = 83 "afr 9/11/1998 19:50" "Object>>perform:[with:...]" ifTrue: [^self send: arguments first to: receiver with: arguments allButFirst super: false]. primitiveIndex = 84 "afr 9/11/1998 19:50" "Object>>perform:withArguments:" ifTrue: [^self send: arguments first to: receiver with: (arguments at: 2) super: false]. primitiveIndex = 188 ifTrue: [ arguments size = 2 ifTrue: [ "eem 5/27/2008 11:10 Object>>withArgs:executeMethod:" ^MethodContext sender: self receiver: receiver method: (arguments at: 2) arguments: (arguments at: 1) ]. arguments size = 3 ifTrue: [ "CompiledMethod class >> #receiver:withArguments:executeMethod:" ^MethodContext sender: self receiver: (arguments at: 1) method: (arguments at: 3) arguments: (arguments at: 2) ] ]. primitiveIndex = 189 ifTrue: [ "Object >> (#with:)*executeMethod" ^MethodContext sender: self receiver: receiver method: arguments last arguments: arguments allButLast ]. "Closure primitives" (primitiveIndex = 200 and: [receiver == self]) ifTrue: "ContextPart>>closureCopy:copiedValues:; simulated to get startpc right" [^self push: (BlockClosure outerContext: receiver startpc: pc + 2 numArgs: arguments first copiedValues: arguments last)]. ((primitiveIndex between: 201 and: 205) "BlockClosure>>value[:value:...]" or: [primitiveIndex between: 221 and: 222]) ifTrue: "BlockClosure>>valueNoContextSwitch[:]" [^receiver simulateValueWithArguments: arguments caller: self]. primitiveIndex = 206 ifTrue: "BlockClosure>>valueWithArguments:" [^receiver simulateValueWithArguments: arguments first caller: self]. primitiveIndex = 120 ifTrue:[ "FFI method" value := meth literals first tryInvokeWithArguments: arguments. ] ifFalse:[ arguments size > 6 ifTrue: [^PrimitiveFailToken]. value := primitiveIndex = 117 "named primitives" ifTrue:[self tryNamedPrimitiveIn: meth for: receiver withArgs: arguments] ifFalse:[receiver tryPrimitive: primitiveIndex withArgs: arguments]. ]. ^value == PrimitiveFailToken ifTrue: [PrimitiveFailToken] ifFalse: [self push: value]!

1 0

Fwd: [vwnc] Smalltalk for small projects only?
by Janko Mivšek 30 Jan '12

30 Jan '12

-------- Prvotno sporočilo -------- Zadeva: Re: [vwnc] Smalltalk for small projects only? Datum: Mon, 30 Jan 2012 19:27:31 +0000 Od: Niall Ross <niallfr(a)btinternet.com> Dear Janko, (tried to send this to Pharo and squeak mailing lists as well as well as vwnc and you - got a hiccough; trying again just to vwnc and you). The largest Smalltalk project I've experienced was Kapital. They were approaching 70 developers in 4 locations in 2005 and IIUC are larger now. They use an in-house process based on Envy. Frequent rebuilding of images is forced by aging of Envy repositories, properly committed stuff being copied over. Thus developers are obliged to use correct process or lose code. I described the process briefly in a secondary talk (not my main one) at ESUG 2004, and Jan Monclair gave more recent info at ESUG 2008 and ESUG 2009 (see my reports on the ESUG website). A developer I knew there had practical experience of a rival's attempt to replicate their achievement in Java, using comparable resources, that crashed and burned. I've worked in two teams of 15 - 20 developers (one on a single site, one at two sites), each of which were verifiably matching systems maintained by ~100 developers in rivals. These were both in the insurance domain. In one of these, Envy-based, each developer rebuilt their image each day - the process took quite a few minutes but was valuable. In the other, images were eternal (yes, I do mean that!); it would take a long time to describe their process and even longer to convince readers that, contrary to what I at first thought and what most of you will think, it was a viable development process. All the other Smalltalk teams I've worked in, prior to coming to Cincom, were in single figures and used Store or Envy. One of them was verifiably rivalling a sytem of 10s of people in another language. Conclusions: 1) As your Smalltalk project gets large, you will need to put process and tools in place on top of what Envy, or Store, or, as Dale says, Monticello and Metacello, give you out-of-the-box at the moment. (It is news to me if Java projects of 200 people do not find the same, but I defer to those with more - which means any - experience of being in a 200-person Java project to correct me if that is not so - or is less so in some important respect.) It would be good if Smalltalk projects that find themselves growing into this area could get a tool/add-on that conveyed existing experience and solutions instead of having to re-roll their own superstructure on existing tools. (In Cincom, we are attempting to use our own development-process and build-process-improvement work to achieve this.) 2) Combining Kapital experience with the ratio one can justify between 'Smalltalk developers needed to do' and 'Java developers needed to do', persuades me that there is no limit on the complexity of problem Smalltalk can attack relative to its rivals. 3) I agree with Dale that making the minumum image smaller is the way to go. (Again, we wish to do this in VW; as always, such efforts progress slowly in background while we meet immediate requirements.) Yours faithfully Niall Ross -- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

1 0

Re: Smalltalk for small projects only?
by Janko Mivšek 30 Jan '12

30 Jan '12

Wow guys, it is nice for me to see that this thread raised some fruits already and it seems it will even more in the future :) Best regards Janko S, Dale Henrichs piše: > Otto, > > This looks very interesting! Since you are still using Monticello, I think it should be very straightforward to add the file tree repository type to Metacello as a starting point, although I'm sure that more support is needed than just that.. > > I am in the middle of working on the next release for Metacello, so now is a good time to integrate smallsource support into Metacello, please drop me a line and give me your thoughts on the direction you think things need to go... > > Dale > > ----- Original Message ----- > | From: "Otto Behrens" <otto(a)finworks.biz> > | To: Pharo-project(a)lists.gforge.inria.fr > | Sent: Sunday, January 29, 2012 2:03:42 PM > | Subject: Re: [Pharo-project] [squeak-dev] Re: [Smalltalk for small projects only? > | > | Hi, > | > | We've built a little package that allows us to save all our source in > | git. We've been developing with this for 3 months now, and it's > | pretty > | stable. I put a project on github, > | https://github.com/finworks/smallsource that contains some more info > | on it. Yes, there's more work to do, but there's hope. The repo > | contains some examples that I just saved from the image. > | > | In short, we save and load all the monticello packages on our project > | as smalltalk source files. We use git to merge and not monticello. We > | use metacello, but watered down to essentially just dependencies. > | > | I just want to say thanks to all you people who put in such great > | effort into Smalltalk. We are using Smalltalk to create a business > | and > | are slowly getting somewhere. > | > | We've been using git for about 3 years now. This came from a need to > | manage files, such as scripts, resources (images and stuff), > | documents > | and recorded selenium (ide) tests with smalltalk code. So, we just > | whacked all of this, including our monticello packages into the git > | repo. > | > | As you can imagine, storing binary files in a git repo, especially > | fairly large packages and lots of integrations / merges / versions, > | grew the git repo quite a bit. We also needed to clone the git repo > | all over. So we decided to give it a shot and write to files. > | > | It took about 2 weeks to get going and another to sort out some pain, > | but the package in the smallsource repo have not changed for 3 > | months. > | > | We are 5-6 developers on the project, committing numerous times a > | day. > | We currently have about 1100 classes (find repo -type d | wc -l > | gives > | us 2200) and 23500 methods (find . -type f | grep -v "mcz$" | wc -l > | gives us 23545) managed in this way. > | > | I'm keen to talk about how we can really "do the right thing" and > | solve this source code management monster. I know this approach needs > | work (I'll list some issues on the project, that I think needs > | attention) and I also realise that there could be better approaches. > | > | Here's another idea: we can map class definitions and method > | definitions directly to git objects. Git has a great object model > | which will allow us to directly track the complete history of a > | method > | or class definition, with commit details and what not. In a sense, I > | feel that a tight integration between a smalltalk environment and git > | will be a fantastic solution - something like envy, but on git, with > | all the fanciness that comes with git! > | > | The only problem with this is a very tight coupling with git. Do we > | want that? > | > | Thanks again > | Otto > | > | > > -- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

1 0

alternate base libraries was Re: Smalltalk for small projects only?
by David Corking 29 Jan '12

29 Jan '12

Mkobetic's piece is absolutely germane: any application in any language is an image, so a focus on Smalltalk's image is a distraction for those who don't want it. Also - any language also has a 4GB image limit in a 32-bit x86 system. Meanwhile, other devs and admins come to the idea of freeze-dried objects through VMware/VirtualBox or filesystem and DBMS snapshots: where they are seen as extra value, rather than harmful. To get the benefit of images, you don't need to be able to replay every transaction or instruction from bare metal, just from a known stable state. However, I would like to pick a bone with Dale's suggestion, if he will permit me. He said: > when you have a micro-image as a starting point it is much easier to consider and > use alternate base library implementations which in turns make it easier to > move the language forward I am uncomfortable with this, as the Pharo/Squeak experience suggests that most libraries that have been pulled out of the image and stored in Monticello (or its predecessors) to allow experimentation have suffered quickly from bitrot. I suggest that the bitrot has not been due to the development process, as it is quite easy to automate reintegration into release or trunk images, but instead that the Smalltalk community, at least the community of open source developers of the main images, is just too small . Seaside, which runs in so many different Smalltalks, has been a success story, but my fear is that it may be the exception that proves the rule: it has a community of dedicated developers that makes sure that the entire library always compiles and runs on every release of Pharo, Squeak, VW and Gemstone. It is true that things inside the image also suffered bitrot: for some there is a good reason for a loss of interest, and for others I think the small size and huge creative energy of the community may be the cause. However, I don't think that in general that the community is big enough to support much language experimentation by this route. It seems to me that experiments like STEPS, Newspeak, Self, Strongtalk, Croquet and closure support have worked without a widespread diversity of base libraries in the rest of the developer community. As far as I can tell, and I may be wrong, even the vast C and Java communities don't have a vast diversity of important libraries that they experiment with: on the contrary, migrations say from libc to libc2 or AWT to Swing need careful management. Libraries that don't get the support of the big vendors die all the time. Just my 2p from my observations of community dynamics, as you know that I don't have a deep personal investment in any of the libraries, even my favourite Morphic/Etoys. David.

3 3

making a voice recording
by Chris Muller 29 Jan '12

29 Jan '12

I just know I've used the voice-recorder before and it worked. But now I'm trying to record a phrase and getting garbled results. It's strange -- it's definitely my voice but as if the recording is missing lots of short sections.. I went all the way back to a stock Squeak 3.8 with the 2202 VM. It had the same problem. Which makes me wonder whether there's something wrong with my Linux driver? But Ubuntu's voice recorder seems to work fine.. Is the in-image voice recorder (found in the object catalog) working for anybody?

4 3

Re: FOSDEM2012 smalltalk devroom 5 feb, sprint 4 feb
by Marcus Denker 29 Jan '12

29 Jan '12

> 09:30 Norbert Hartl, Take a small REST. Simple approaches for REST in smalltalk > 10:00 Stephane Ducasse, Marcus Denker, The next steps for the Pharo Vision > I checked for trains... the *first* train from Lille arrives 9:45 in Bruessels Midi Sundays. I don't feel like booking a Hotel in Bruessels, I have to admit. -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

1 0

Garbage Collection visualization for Squeak VM
by Crazy Java 29 Jan '12

29 Jan '12

Hi Squeak VM guys, few weeks ago I was chatting with some of you on the IRC channel about GCSpy. GCSpy is a Garbage Collection visualization tool written in Java (currently a little bit outdated). It consists of 2 parts: server (which has a C/C++ connector to the VM implementation) and client (java application). Because of this demarcation, it is not tight to any specific VM or language. I am working on its rewrite and currently gathering ideas what could be improved (architecture, code, abstractions, ...). If you are interested in, I wrote a document about the proposed changes and I am looking for further ideas. It will be great if you can provide any kind of feedback (general as well as what will be nice to add according to Squeak VM, ...). Thanks, Martin Skurla Software Engineer Email: crazyjavahacking(a)gmail.com Blog: crazyjavahacking.org

1 0

Why does BouncingAtomsMorph fudge bounds
by Sean P. DeNigris 29 Jan '12

29 Jan '12

AtomMorphs take their topLeft as their position. This causes them to bounce past the bottom and right edges of their container by "atom width" and "atom height" respectively. Then, BouncingAtomsMorph comes to the rescue in #step with: r _ bounds origin corner: (bounds corner - (8@8)). Why was this done this way? Was it to make the AtomMorph's method look like more purely like a mathematical formula for a particle? If so, this makes sense, but a comment documenting the intent would be really nice. Sean -- View this message in context: http://forum.world.st/Why-does-BouncingAtomsMorph-fudge-bounds-tp4337653p43… Sent from the Squeak - Dev mailing list archive at Nabble.com.

2 1

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