- Pharo-dev - lists.pharo.org

[Pharo-project] Re: Removing default fonts

by Markus Fritsche

Adrian Lienhard schrieb: > In another thread (Pharo image size: 10.9MB) I proposed to remove all > but one font since the ones in the image (especially the TT fonts) > are not really useful but consume memory. Hilaire suggested to keep > Accujen, which to my eyes looks better than the default Accuny font > (not perfect, but better..). Does somebody have a "font load/ unload" process in mind? Fonts once removed in vanilla squeak are a PITA to load back and re-anchor in the system-wide font collections... So basically, I'd like to vote for "remove and make loadable steph by steph"

Oct. 17, 2008

[Pharo-project] New pharo dev

by Damien Cassou

New pharo-dev available at http://code.google.com/p/pharo/wiki/Downloads?tm=2. It only contains the package you want (http://code.google.com/p/pharo/wiki/Packages) -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

Oct. 17, 2008

Re: [Pharo-project] Re: Universe Browser - search

by Damien Cassou

Hi Dan, On Tue, Oct 14, 2008 at 10:47 PM, Dan Corneanu <dan.corneanu(a)gmail.com> wrote: > I've put up a small change set with fixes as suggested in > http://bugs.squeak.org/view.php?id=6798. > > I have tested the change set in pharo0.1-10082dev08.10.1 and it works OK. > A comment on the OBNode>>isDescendentOf: method would have spared me a > lot of effort. > I had a hard time finding out that self isDescendentOf: self should return true. I've included the fix. Next dev images will contain it. Thank you very much. If you have a sentence or two that would make a good comment for #isDescendentOf:, I would publish it. You can also publish it yourself to http://source.wiresong.ca/ob (read/write access to everyone). -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

Oct. 17, 2008

Re: [Pharo-project] About nextPut:

by Damien Cassou

On Thu, Oct 16, 2008 at 3:52 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Now I was wondering if there is way to avoid that. A stream can be seen as a pointer between past and future sequence values. Which means there must be a way to index the element in the collection of data and this is not the case with Sets. In the case of #flatCollect:, you do not want a stream, you want a generic way to add data to a collection of elements. I don't see any generic way to do this. -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

Oct. 17, 2008

Re: [Pharo-project] One click feature list request/question

by Antony Blakey

On 17/10/2008, at 6:08 PM, Marcus Denker wrote: > Of course, the question always is what means "interested in this", > in the light of no funding and limited spare time? I'm not au fait with the detailed history of Squeak, but I know that you've been at the pointy end of the thankless and shitty task of harvesting for release, so I mean no disrespect, and acknowledge that it is a problem. However ... I had no external funding and limited time and yet I managed to make LLVM/Clang work in VW, as well as many other things. I've found that ST can be phenomenally productive for these kind of things, especially when you a) you don't try to solve every problem, esp. in every 'market' that uses Squeak; and b) you leverage existing codebases such as LLVM/Clang/WebKit/GIT etc. <rant> IMO Smalltalk's fatal flaw is it's lack of modularity and good system construction. Pharo is one kind of process, but IMO a more fundamental rethink of system construction mechanisms is required, at all granularities. IMO the #1 priority should be dealing with this problem which has burdened Smalltalk since it's inception. It's particularly problematic in Squeak because it tries to address so many uses, there's so much stuff added to Squeak, and often then abandoned, and no one seems to do any serious documentation of any architecture or implementation, apart from a few Traits papers and one OB paper. </rant> I've found it more productive to completely replace components rather than attempt to untangle the mess that it is e.g. a typical GUI component. I've developed a very productive way of doing that involving class cloning, hierarchy collapsing and brutal simplification. I think 90% of the entanglement problem is in Morphic, so being brutal there, which can be accomplished by focussing on keeping OB working and letting just about every other GUI tool rot, is a productive strategy. I'm greatly enhancing OB, and by relying on it's abstraction from the GUI (and using OB-Tools) Squeak can be kept usable whilst pruning with a chainsaw. I can do this because I'm not trying to produce a system that is backwards compatible in any sense, primarily because I've implemented a solution to the system construction/modularity problem, so I'm trying to reboot to a from-source modular bootstrap. Thus, my mileage will vary compared to people with other constraints. So I suppose by 'interested' I mean 'interested in LLVM/Clang in the context of a far more brutal reboot than Pharo'. I guess skepticism is warranted, and I failed to garner interest in the VW community in spite of providing proof-of-concept demonstrations for my proposals, so I admit I'm fishing (although not, I hope, trolling) :) Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 He who would make his own liberty secure, must guard even his enemy from repression. -- Thomas Paine

Oct. 17, 2008

Re: [Pharo-project] One click feature list request/question

by Marcus Denker

On 16.10.2008, at 10:40, Antony Blakey wrote: > Anyone else interested in this? Sounds cool! Of course, the question always is what means "interested in this", in the light of no funding and limited spare time? Marcus > I did some work to integrate LLVM and Clang with VW. I'm moving this > to Squeak. For the platforms supported by LLVM this allows inline C/ > ObjC/C++ (although C++ is early days yet), dynamically compiled and > loaded, and highly optimized platform-independent SSA-based native > code generation. As a side effect it can provide an optimized FFI > based on jitted stubs/trampolines. I did this (trivially) for > callout in VW, but didn't bother about callbacks. You can also use > Clang to parse platform headers (and code), which you can obviously > include in inline C, and also produce a parse tree with various > degrees of semantic analysis, which you can then reflect on. Clang > goes to extraordinary lengths to maintain source correspondence, > which is an added bonus in interactive environment such as Smalltalk. > > Eliot's aware of that work. AFAIK he decided against using LLVM for > Cog because Qwak wanted something that didn't increase the VM > footprint, although he probably had some other reasons as well. PICs > were an issue he raised, but that can be dealt with - in fact, by > using runtime type recording at the call sites, plus some techniques > used in multi-method dispatch for CLOS, you can optimize for both > sides of a double dispatch, which would given at the very least > highly optimized numeric operations. LLVM also does cool link time > optimization and inlining, and I've got this (largely unformed) idea > that the type-based specialisation could possibly trickle back along > a call chain, resulting in block-aggregation that would expose more > opportunity for optimization by delimiting regions of known type > information. It might be however that such regions never practically > get above a certain size. > > I'd like to investigate using LLVM to make plugins that are > dynamically compiled and loaded (i.e. not via VMMaker). A further > thought is that the VM could be regenerated, compiled and switched > whilst running. This leads obviously to a *very* basic cross- > platform headless VM that regenerates itself upon loading, optimized > for the platform it's running on. Of course you'd cache this. > > Benefits of LLVM/Clang over roll-your-own native code generation are > a) the significant optimization systems; b) cross-platform code > generation; and c) dynamic C-family integration. > > And finally, LLVM/Clang are two of the most beautifully, cleanly > architected and written pieces of C++ code I've ever seen. No, I'm > not a contributor :) > > > On 16/10/2008, at 6:33 PM, Alexandre Bergel wrote: > >> Talking about interoperability. I did some experiment a while ago >> about making Squeak talk to Java using sockets. Java classes are >> accessible within Squeak, and reflection is used to invoke methods. >> People interested in this could ask for further info. >> >> Cheers, >> Alexandre >> >> On 16 Oct 2008, at 09:55, Lukas Renggli wrote: >> >>>> But then, the new FFI of Eliot seems to be far, far better then >>>> the old >>>> one. >>>> It would be nice to have that instead. E.g, it supports callbacks >>>> nicely >>>> and >>>> is much faster. >>> >>> Go Eliot, go! It is crucial that Smalltalk gets better bindings with >>> the outside world. It should be easy (as with Python or Ruby) to >>> integrate some external C library. >>> >>> I hope the new FFI doesn't need to hack the Smalltalk language and >>> compiler. >>> >>> Cheers, >>> Lukas >>> >>> -- >>> Lukas Renggli >>> http://www.lukas-renggli.ch >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > Antony Blakey > ------------- > CTO, Linkuistics Pty Ltd > Ph: 0438 840 787 > > When I hear somebody sigh, 'Life is hard,' I am always tempted to > ask, 'Compared to what?' > -- Sydney Harris > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Oct. 17, 2008

Re: [Pharo-project] Re: [ANN] new 10095 prebuild image

by John McIntosh

On Fri, Oct 17, 2008 at 12:07 AM, Marcus Denker <denker(a)iam.unibe.ch> wrote: > > On 16.10.2008, at 21:38, nicolas cellier wrote: > >> Marcus Denker <denker@...> writes: >>> >>> >>> Yes, I will try to update the windows vm, too. >>> >>> In addtion, we should fix the Logo. >>> >>> Marcus >> >> >> By the way, >> what is the recommended VM? > > For now, I use the Squeak 3.8.18beta1U vm. I don't even know if there is a > newer one... That would be the 3.8.18beta4U vm 3.8.18b4 Use NANO-SLEEP logic to ensure sleep is accurate to millisecond, no-usage which is more CPU friendly would give upwards of 10ms error to delays which is unacceptable. Fix issue with arguments passed as parms to the VM, the parm number (2) was treated as being special by the carbon vm for historical reasons, but in fact it was not actually set. Try to follow the generic unix rules instead. 3.8.18b3 Compile with xcode 2.5.x on powerpc machine os-x 10.4.x set utf832code field to zero on fake wheel event up/down/left/right arrows print more diagnostic data on failure to allocation virtual memory on browser plugin setup 3.8.18b2 The Sophie team noticed that InternetConfiguration getMacintoshFileTypeAndCreatorFrom: 'test.jpg' This returns byte reversed data on macintel #('GEPJ' 'elgo') sqMacInternetConfiguration.c use CFSwapInt32BigToHost swap OSType -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Oct. 17, 2008

Re: [Pharo-project] Re: [ANN] new 10095 prebuild image

by Marcus Denker

On 16.10.2008, at 21:38, nicolas cellier wrote: > Marcus Denker <denker@...> writes: >> >> >> Yes, I will try to update the windows vm, too. >> >> In addtion, we should fix the Logo. >> >> Marcus > > > By the way, > what is the recommended VM? For now, I use the Squeak 3.8.18beta1U vm. I don't even know if there is a newer one... > > I use a 3.10vm, and without http://bugs.squeak.org/view.php?id=7071, > accented > key strokes are a mess (they open Debuggers). So the 3.10 vm does not work on windows with a 3.10 image? Very cool. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Oct. 17, 2008

[Pharo-project] Re: Cannot browse senders of #binary

by nicolas cellier

StÃ©phane Ducasse <stephane.ducasse@...> writes: > > Hi nicolas > > This is strange because if I type binary and press alt N or Alt m > I get them. Then if I do the same with #binary I do not get anything. > can you tell me more? > Because I used senders and implementors like a mad to curve etoy. > Stef > Ah, indeed, this works in a fresh image, and it is hard to reproduce. However, if you read code (MessageSet >> #methodDisplayStringForClass:selector:), you will see that this line is wrong: nextPutAll: (PackageOrganizer default mostSpecificPackageOfClass: class ifNone: '***') packageName ; Potentially, it can send #packageName to '***'. How did I trigger the ifNone: '***' ? I think it is because while patching SLICE-Mantis-6933-MultiByteFileStream-upTo-nice.1, I created a new category (MultilingualTests) with no corresponding package. So create a class with a new category: Object subclass: #AnUnpackagedClass instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'NimporteQuoi' Then compile AnUnpackagedClass >> #triggerTheBug ^self binary Then browse senders of binary... You see it? That's a minor bug, but code must be changed. Nicolas

Oct. 17, 2008

Re: [Pharo-project] copy dependent packages

by Michael Roberts

hah! I was thinking just the same thing when you figured out why my last slice didn't work. +1 for that feature. Mike

Oct. 16, 2008