February 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Pharo changing the game

by Philippe Marschall

On 12.02.2010 00:26, John M McIntosh wrote: > Er, maybe I'll rant here since it' seems to me this the day for that. Perhaps flavoured a bit with > Ralph's accidental post about cilantro. > > Should we not be talking about the Smalltalk 2010 ANSI proposal? Why the lock in to the > Smalltalk ANSI INCITS 319-1998 (R2002) standard? Because even very basic things like Strings, Symbols and Numbers are a minefield that behave in slightly different ways. And you won't find out until later. I don't want to know how many weeks we wasted on #seasideString. Cheers Philippe

Feb. 12, 2010

Re: [Pharo-project] [Slightly OT] Integers smarter than me today

by Schwab,Wilhelm K

David, I will try your test, subtract+negate algorithm. On extending the highest bit, what is the reason for stopping at 16? I thought of something similar, but assumed I should cover all bits used in representing a small integer?? Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of dpharris(a)telus.net Sent: Thursday, February 11, 2010 8:00 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [Slightly OT] Integers smarter than me today Assuming these are 12bit signed numbers, then I think the answer is that you should extend the 12th bit out to the 16th bit position. The conversion should be 0..2047 (0x000..0x7FF) => 0..2047, and 0x4095..0x2048 (0xFFF..0x800) => -1..-2048. So, it is probably easier to keep the numbers less than 2096, and for those those bigger than 2047, subtract them from 4096 and negate. David Quoting "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu>: > Hello all, > > I am trying to make a recognizer for a communication protocol that has > very likely been errantly documented. Such tasks can be difficult > enough with good docs, but I'm not even sure what is supposed to be > happening, so it is really interesting. > > One of the things that I **think** is happening, is that 12-bit two's > complement data is included at one point in the stream. The bits are > spread over a 16 bit word. Let's assume that I can correctly gather > the 12 bits together. Could some kind soul suggest how to go from the > resulting SmallInteger to the correct signed value? Smalltalk is > adding a wrinkle that I am not sure how to handle: should I set the > "missing" bits to 1? Out to bit 31? > > Any pointers/suggestions would be greatly appreciated. > > Bill > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 12, 2010

Re: [Pharo-project] [Slightly OT] Integers smarter than me today

by dpharris＠telus.net

Assuming these are 12bit signed numbers, then I think the answer is that you should extend the 12th bit out to the 16th bit position. The conversion should be 0..2047 (0x000..0x7FF) => 0..2047, and 0x4095..0x2048 (0xFFF..0x800) => -1..-2048. So, it is probably easier to keep the numbers less than 2096, and for those those bigger than 2047, subtract them from 4096 and negate. David Quoting "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu>: > Hello all, > > I am trying to make a recognizer for a communication protocol that has very > likely been errantly documented. Such tasks can be difficult enough with > good docs, but I'm not even sure what is supposed to be happening, so it is > really interesting. > > One of the things that I **think** is happening, is that 12-bit two's > complement data is included at one point in the stream. The bits are spread > over a 16 bit word. Let's assume that I can correctly gather the 12 bits > together. Could some kind soul suggest how to go from the resulting > SmallInteger to the correct signed value? Smalltalk is adding a wrinkle that > I am not sure how to handle: should I set the "missing" bits to 1? Out to > bit 31? > > Any pointers/suggestions would be greatly appreciated. > > Bill > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 12, 2010

Re: [Pharo-project] Pharo changing the game

by Eliot Miranda

On Thu, Feb 11, 2010 at 3:26 PM, John M McIntosh < johnmci(a)smalltalkconsulting.com> wrote: > Er, maybe I'll rant here since it' seems to me this the day for that. > Perhaps flavoured a bit with > Ralph's accidental post about cilantro. > > Should we not be talking about the Smalltalk 2010 ANSI proposal? Why the > lock in to the > Smalltalk ANSI INCITS 319-1998 (R2002) standard? > I haven't seen much movement since Bruce kicked it off ( http://openskills.blogspot.com/2007/10/ansi-smalltalk.html) One of the hurdles was the amount of money ANSI wanted for participation in the standard. I for one couldn't afford it and couldn't see how Cadence, my then employer, would fund it. I think that goes for most of the non-vendor community. See Clay Shirky's TED presentation<http://www.ted.com/talks/clay_shirky_on_institutions_versus_collaboration.h…>on institutions for why IMO ANSI is a non-starter. ANSI is irrelevant; it meets it's own needs, not the needs of the Smalltalk community. It can only ever create an obsolete standard. We need to design our own standard that meets our needs. If we can design a standard that is relevant the community as a whole will increasingly adhere to it over time, and as that happens it will become more useful, and, because it is defined by us, can evolve over time, both in content and at a meta level in its standards-making processes. > I think this fits into Stephane's comment about moving forward. > IMO, moving forward means finding new forms, not putting a new badge on the same old corpse. We need a sci-fi movie not a zombie movie ;) > On 2010-02-11, at 1:51 PM, Lukas Renggli wrote: > > > >> Now why don;t people want a better smalltalk? > > > > Sure, everybody wants a better Smalltalk. > > > > The ANSI standard does not make scripting impossible, it does not > > forbid first class instance variables, it does not forbid a MOP or a > > module system. > > > > The ANSI standard only talks about the basic Smalltalk syntax, > > Collections, Magnitudes, Streams. That's it. I don't think it is > > limiting in any way. > > > > 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 > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 11, 2010

Re: [Pharo-project] Pharo changing the game

by John M McIntosh

Er, maybe I'll rant here since it' seems to me this the day for that. Perhaps flavoured a bit with Ralph's accidental post about cilantro. Should we not be talking about the Smalltalk 2010 ANSI proposal? Why the lock in to the Smalltalk ANSI INCITS 319-1998 (R2002) standard? I think this fits into Stephane's comment about moving forward. On 2010-02-11, at 1:51 PM, Lukas Renggli wrote: >> Now why don;t people want a better smalltalk? > > Sure, everybody wants a better Smalltalk. > > The ANSI standard does not make scripting impossible, it does not > forbid first class instance variables, it does not forbid a MOP or a > module system. > > The ANSI standard only talks about the basic Smalltalk syntax, > Collections, Magnitudes, Streams. That's it. I don't think it is > limiting in any way. > > 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 -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Feb. 11, 2010

Re: [Pharo-project] [squeak-dev] Re: 16rff is looking for a fix :)

by Eliot Miranda

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 > > >

Feb. 11, 2010

Re: [Pharo-project] Pharo changing the game

by Eliot Miranda

On Thu, Feb 11, 2010 at 1:28 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > > get stuck with a ANSI bad standard? > > The ANSI standard is not bad. It is minimal, maybe too minimal? But it > does not forbid anything like #and:and: or Traits. The ANSI standard > gives a minimal common dominator. It is absolutely essential to > projects like Monticello, OmniBrowser, SUnit, Seaside, Magritte, Pier, > ... > I think at best it's a curate's egg<http://en.wikipedia.org/wiki/Curate%27s_egg> . First it's hard to browse and lots of the names are un-Smalltalky. Second, it doesn't standardize Smalltalk, only its core libraries. It's all very well to specify a minimal library, but to leave the vast array of reflective facilities unspecified is, for Smalltalk, a huge mistake. The standard, if it wasn't an attempt at a rubber stamp by the vendors, have included optional sections. So that were an implementation to include execution reflection (thisContext) the standard could define what that looked like, but not require an implementation to include execution reflection. The same goes for run-time class creation and method definition. Third, it isn't an extensible standard. If it were forward looking the standard would have put in place some mechanism for adding to the standard (such as a voting scheme) so that over the years excellent extensions to the base library such as beginsWith: first: et al could be added. It would also have defined the kind of versioning facilities that people need to know what version of the standard they can expect (we recently discussed something similar in the context of Metacello and Grease on the Pharo list). There needs to be a global object which can be queried for version information, what core facilities exist and which don't, etc. All of these lacks really hurt projects like Grease (there have been numerous attempts over the years) because there is a raft of dialect-specific code, and one either has to introduce a new global (SmalltalkVersion) or hang the functionality off existing dialect classes (Smalltalk, System, etc, etc). We need a standard that standardises Smalltalk, not C with Smalltalk syntax. Smalltalk is reflective, dynamic and evolves rapidly. That implies a different kind of standard, not overseen by ANSI, whose objective is self-preservation, not standardisation (see Clay Shirkey; do you know how much money ANSI want for a standards process??). We need a living standard that can evolve. I know it is impractical, if not impossible, to standardize the language-development side of Smalltalk, a standard that could extend to e.g. Newspeak. But this is also pointless. No one needs a standard for blue plane. But we have a string need for a standard that standardises Smalltalk as it is used in the industry; one that supports systems like Seaside. There /is/ mutual self-interest in a standard that can help convergence in agreed-upon functionality, that is open, and that can evolve at the right pace (not too fast, or it has no value, not too slow or it has no relevance). Some bright minds at universities that use VW, Pharo, Squeak and VisualAge could do some really interesting work here. The dialects, including those from the vendors, would surely be willing to pitch in if the standard was what Smalltalk is, malleable, incremental, open, comprehensible. best Eliot > Now Seaside is developed on pharo and run on nearly all the dialects so > there > > is a path. It is not easy. > > Because we strictly adhere to the ANSI standard and because we have > our own platform layer called Grease. > > http://blog.fitzell.ca/2010/01/easing-compatibility-with-grease.html > > 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 >

Feb. 11, 2010

[Pharo-project] [Slightly OT] Integers smarter than me today

by Schwab,Wilhelm K

Hello all, I am trying to make a recognizer for a communication protocol that has very likely been errantly documented. Such tasks can be difficult enough with good docs, but I'm not even sure what is supposed to be happening, so it is really interesting. One of the things that I **think** is happening, is that 12-bit two's complement data is included at one point in the stream. The bits are spread over a 16 bit word. Let's assume that I can correctly gather the 12 bits together. Could some kind soul suggest how to go from the resulting SmallInteger to the correct signed value? Smalltalk is adding a wrinkle that I am not sure how to handle: should I set the "missing" bits to 1? Out to bit 31? Any pointers/suggestions would be greatly appreciated. Bill

Feb. 11, 2010

Re: [Pharo-project] Pharo changing the game

by Lukas Renggli

> Now why don;t people want a better smalltalk? Sure, everybody wants a better Smalltalk. The ANSI standard does not make scripting impossible, it does not forbid first class instance variables, it does not forbid a MOP or a module system. The ANSI standard only talks about the basic Smalltalk syntax, Collections, Magnitudes, Streams. That's it. I don't think it is limiting in any way. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 11, 2010

Re: [Pharo-project] Pharo changing the game

by StÃ©phane Ducasse

Now why don;t people want a better smalltalk? >> get stuck with a ANSI bad standard? > > The ANSI standard is not bad. It is minimal, maybe too minimal? But it > does not forbid anything like #and:and: or Traits. The ANSI standard > gives a minimal common dominator. It is absolutely essential to > projects like Monticello, OmniBrowser, SUnit, Seaside, Magritte, Pier, > ... > >> Now Seaside is developed on pharo and run on nearly all the dialects so there >> is a path. It is not easy. > > Because we strictly adhere to the ANSI standard and because we have > our own platform layer called Grease. > > http://blog.fitzell.ca/2010/01/easing-compatibility-with-grease.html > > 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

Feb. 11, 2010