- Pharo-dev - lists.pharo.org

[Pharo-project] Fwd: Issue 1945 in pharo: registration mechanism for the menu
by StÃ©phane Ducasse Feb. 12, 2010

Feb. 12, 2010

>> >> Comment #2 on issue 1945 by aplantec: registration mechanism for the menu >> http://code.google.com/p/pharo/issues/detail?id=1945 >> >> yep!! >> I've retrieved it (I thought I had lost it and I was sad) >> it is the MenuRegistration package in PharoTaskForces. >> Try it with: >> -------------- >> PragmaMenuBuilder popUpKeyword: 'worldMenuExample' title: 'World menu'. >> -------------- >> >> This example popups a world menu fully declared with pragma methods. >> It also shows how an external package can register a new entry in it >> (see WorldMenuSkeletonExample class>> myOwnCoolToolRegistrationOn: and >> WorldMenuSkeletonExample class>> myOwnCoolMenuRegistrationOn: ) >> The principle is exactly the same as for the settings. > > Sounds like quite cool to me.

1 0

[Pharo-project] [update 1.1] #11204
by Marcus Denker Feb. 12, 2010

Feb. 12, 2010

11204 ----- Issue 1906: changeStampPerSe and changeStamp should be moved from Utilities to Author Issue 1956: clean mutiCS, multiSt Issue 1905: Date and DateAndTime behavior should be extracted from Utilities -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

[Pharo-project] ProfStef Metacello Tutorial
by laurent laffont Feb. 12, 2010

Feb. 12, 2010

Hi I've just seen there's a MetacelloConfigurationTutorial for ProfStef. http://code.google.com/p/metacello/ In 'http://seaside.gemstone.com/ss/metacello' repository, package Metacello-ProfStef. Laurent Laffont

1 0

[Pharo-project] labeled or labelled?
by Torsten Bergmann Feb. 12, 2010

Feb. 12, 2010

Question to native english speakers, what is correct: a) MyClass labeled: 'foo' b) MyClass labelled: 'foo' for a class MyClass defining an instance variable "label". Me and google would tend to a) but there is a method #labelled: on SystemWindow. Thx T. -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

2 1

Re: [Pharo-project] [squeak-dev] Re: 16rff is looking for a fix :)
by Eliot Miranda Feb. 11, 2010

Feb. 11, 2010

On Thu, Feb 11, 2010 at 2:59 PM, Andreas Raab <andreas.raab(a)gmx.de> wrote: > Eliot Miranda wrote: > >> this in the thread spawned by Torsen's posting of Kent's most excellent >> rant: >> ttp://www.threeriversinstitute.org/blog/?p=466 < >> http://www.threeriversinstitute.org/blog/?p=466> >> >> <http://www.threeriversinstitute.org/blog/?p=466>OK, fix is to two >> implementations of digitValue:. BTW, I haven't fixed Character >> class>>digitValue: which at least in my Teleplace image looks horribly >> broken, answering characters not integers. Check your distro, it may also >> be broken >> > > It's not. It works precisely as advertised (rtfc). What's confusing is that > EncodedCharset and Unicode use the selector #digitValue: when the selector > should be called #digitValueOf: (i.e., returning the digit value OF a > character not creating a new character with a given digit value in this > character set). > Doh! > > Besides, I very much doubt that the change in hex literals (which I'm very > much in favor of btw!) will address Kent's issue. I agree. But every little bit helps :) > The reality is that there's no way to address his issues because there's no > single owner of the brand. Balkanization (which is precisely the right term) > happens when you don't have a strong central power which can keep everyone > at bay (such as Yugoslavia did before it fell apart). Java for example is > owned by Sun and Sun went to court with Microsoft to ensure brand integrity. > Unless you have an owner of "Smalltalk" (whatever that is) there isn't going > to be a consistent set of libraries because everyone can and will push into > different directions. > I disagree. I think the community has managed to agree on the utility of several things. Many of the Squeak collection extensions have found their way into VisualWorks for example because they're clearly useful and convenient. I think the problem with the standard is architectural, and that that architectural limitation was built-in from the get-go It was intended to be something the vendors could agree upon, not a useful standard. The issue for the vendors was in having a check-box for Smalltalk compared to other languages; C had a standard, C++ had a standard, so Smalltalk needed one. ut the standard wasn't useful for the community, and I think as a result hasn't been that useful for the vendors. Being x3j20-compatible didn't mean enough. But at the time things were very different. Test suites were not in widespread use and no one had developed one yet. A good thing to come out of x3j20 and the first CampSmalltalk was a test suite. The web was in its infancy; there was no javadoc or www.python.org/doc/. Squeak was very young. So it's not surprising that the standard failed to be that useful. The world changed very quickly soon there-after. A differently-architected standard could be useful and a gently unifying force. But it needs to address the challenges of standardising Smalltalk as it exists in its current context, not as it was in the early 90's. > Cheers, > - Andreas > > >

1 0

[Pharo-project] 16rff is looking for a fix :)
by StÃ©phane Ducasse Feb. 11, 2010

Feb. 11, 2010

2 2

[Pharo-project] Alternative implementation for Cursor>>show:
by Fernando olivero Feb. 11, 2010

Feb. 11, 2010

Hi, i think this send to Sensor could be avoided by replacing the Cursor>>show: method with Cursor>>show self class currentCursor: self. Instead of a: Cursor>>show "Make the hardware's mouse cursor look like the receiver" Sensor currentCursor: self InputSensor>>currentCursor: newCursor "The current cursor is maintained in class Cursor." Cursor currentCursor: newCursor.

3 6

Feb. 11, 2010

hi all Jannik and jb started to replace all the and:and: and:and:and: and:and:and:and: and the same for or: by they equivalent ie 1 =2 or: [ 1=3 ] or: [1=1] => 1 =2 or: [ 1=3 or: [1=1]] the new compiler optimize both while the old one not. So now I would like to see what do you think. Personnally I do not like and:and:and: and more Now for and:and: I'm hesitating. Stef

3 3

[Pharo-project] Help mapping large database objects to Smalltalk objects
by Mariano Martinez Peck Feb. 11, 2010

Feb. 11, 2010

Hi folks: I started to code a bit the large support for SqueakDBX to large objects and I want to ask you for help. In a first step, I will start with the basic large objects: CLOB, NCLOB, XML, BLOB. Now, I need to map each of them, to an Smalltalk object. I though about this: CLOB -> String NCLOB -> String XML -> String and the the user do whatever they want with the string representing the XML. BLOB -> ByteArray what do you think? are there suitable objects in a core image ? (I don't want to depend in another package) Now, do you know which is the faster why to create a ByteArray from a String ? and vice-versa ? just asString ? Another question....to get a field value of a row, I call an OpenDBX using FFI like this: apiQueryFieldValue: handle index: index "const char* odbx_field_value( odbx_result_t* result, unsigned long pos )" <cdecl: char* 'odbx_field_value' (ulong ulong) module: 'opendbx'> ^self externalCallFailed As you can see that function of OpenDBX answer me in a char* the value of the field. The problem is...suppose that field is a large object (a CLOB for example). A Clob can be 1gb or even more....of course, that will be bad for my image (freeze ? crash ? I don't know...). I would like to validate the size of that before bring it into the image, so that not to crash or whatever. I want to put like a limit. The problem is that I don't know how to do that from Pharo side....is that possible ? or the only way is to change OpenDBX side ? Thanks a lot in advance, Mariano

1 0

Feb. 11, 2010

- Issue 1947: Deprecate BlockContext>>fixTemps and BlockClosure>>fixTemps - Issue 1940: More ImageSegment cleaning - remove #fixCapitalizationOfSymbols - remove TTCFontSet code from #comeFullyUpOnReload: This even fixes a cycle dependency between ImageSegment and Multilingual - the following implementors were moved to category *System-Object Storage: *startUpFrom: *saveImageSegments: *areThereImageSegments *rootStubInImageSegment: *scanFromNoCompile: aStream forSegment: anImageSegment Sred

1 0