If you know the endian-ness you want, you can use nextNumber:put: and nextLittleEndianNumber:put: to write out integers in big endian or little endian. So that would probably be the inverse of the methods you were looking for. You can read them back with nextNumber: and nextLittleEndianNumber:.
But why would knowing the machine's ordering matter, unless you are doing primitives? Maybe if you post a higher-level view of what you are trying to do, someone will have a more helpful response. I tend to like the fact that I don't have to think about endianness :)
Lex
"David T. Lewis" lewis@mail.msen.com wrote:
I'm sure I'm missing something obvious, but I'd like to be able to
convert
integers to and from byte arrays in native machine byte ordering,
without
resorting to a new primitive.
- Does Squeak know the byte order convention of the hardware it's
running
on? I can't find any method to query for this.
- Class ByteArray knows how to convert itself into integers, given
that
you can tell it the answer to question 1. Is there any existing
method
for converting an integer into a four byte array?
Thanks.
On Sun, Oct 31, 1999 at 12:38:43PM +0000, Lex Spoon wrote:
If you know the endian-ness you want, you can use nextNumber:put: and nextLittleEndianNumber:put: to write out integers in big endian or little endian. So that would probably be the inverse of the methods you were looking for. You can read them back with nextNumber: and nextLittleEndianNumber:.
Thanks, that's what I was looking for. I don't know why I missed it the first time.
But why would knowing the machine's ordering matter, unless you are doing primitives? Maybe if you post a higher-level view of what you are trying to do, someone will have a more helpful response. I tend to like the fact that I don't have to think about endianness :)
Lex
I'm trying to map a data structure (struct SQFile) in the VM to its corresponding set of objects. The data structure is available as a ByteArray on the Smalltalk side, and I was looking for a quick and dirty way to convert to ByteArray into its corresponding Integers and so forth. This would allow a convenient way to look at the SQFile data structure with normal Smalltalk inspectors.
I suspect that the right way to do this is to rewrite the primitives so they return arrays of objects, rather than raw ByteArrays. But that involves a little more surgury than I wanted to get into.
Further background: It seems to me that there should be no real conceptual difference between an IO channel to a file, and an IO channel to a socket, or to any other external IO channel which can be opened, closed, read, or written to. Presumably these should all look like streams, and presumably we would want socket streams, file streams, and any other streams on external IO channels to behave in similar ways. The specifics of making connections to various types of external IO channels probably merit their own classes, which would know about things like SQFile and SQSocket data structures if needed. I wrote some classes to do this for files and sockets, and it all seems to work very nicely, but I still need a machine independent way to convert the file and socket data structures into Smalltalk objects, hence the question about converting integers back and forth between ByteArrays and Integers.
- Dave
Further background: It seems to me that there should be no real conceptual difference between an IO channel to a file, and an IO channel to a socket, or to any other external IO channel which can be opened, closed, read, or written to. Presumably these should all look like streams, and presumably we would want socket streams, file streams, and any other streams on external IO channels to behave in similar ways. The specifics of making connections to various types of external IO channels probably merit their own classes, which would know about things like SQFile and SQSocket data structures if needed. I wrote some classes to do this for files and sockets, and it all seems to work very nicely, but I still need a machine independent way to convert the file and socket data structures into Smalltalk objects, hence the question about converting integers back and forth between ByteArrays and Integers.
Sounds a bit like Inferno, where every external object, file, printer, socket, network, scanner, other machine, etc. is a "file," manipulated using the traditional file operations of open, close, read, write, position, and each such object is named and accessed using an i-node-like hierarchical naming system.
If you know that the data is coming from that particular machine, you might simply write some pluggable primitive functions longAt:, shortAt: and the like, that do the obvious things, but by casting in the C code rather than trying to "interpret" the data.
This generates "portable" code that has the property that, when the plugin is compiled and installed on each native machine, it will load the data from the ByteArray, interpreting it with the "correct" byte gender for the machine on which it is running. And, of course, once you have those operations, you can test your machine gender simply by loading in an asymmetric bytePattern, say, 16rEAFF and checking the value of a shortAt:
The code is portable in the sense that it will compile on each machine; it will run with the machine's own native data correctly, but is inherently machine dependent, in that images retaining this information may break when copied from machine to machine.
Thus, the code should only be used for machine-dependent purposes or for interpreting highly transient machine local data that will ultimately be stored in non-byteArray (or machine-indepent byteArray) data objects. This is why, I believe, Squeak Central left only the "machine-dependent" operations in ByteArray -- the code yields the same results on every machine everywhere, even though its internals might operate differently.
I have a project that I have been working on and off for awhile trying to model native machine MemoryBlocks, to facilitate machine-dependent manipulation of data, and the coercion/marshalling of data from Squeak to OS and back. The project entailed a hierarchy of classes that would seamlessly understand a block that was stored in a byteArray, stored in system RAM, and pointed to (as pointer, handle or otherwise) from a MemoryBlock, whether internal or external. Using the decorator pattern, the project allows you to define system C records and other datatypes, and refer to them with a nice smalltalk syntax, regardless of whether the C type is stored in a byteArray, in Ram or otherwise. For various reasons, the machine-dependent byteAt:, shortAt, etc. was useful.
Lately, I've been wondering how good such a thing is in principle -- one of the reasons that Java never made the cut of write-once, run-anywhere had to do with a yicky "easy" solution of using machine dependencies to solve problems.
Dave:
Re:
I'm trying to map a data structure (struct SQFile) in the VM to its corresponding set of objects. The data structure is available as a ByteArray on the Smalltalk side, and I was looking for a quick and dirty way to convert to ByteArray into its corresponding Integers and so forth. This would allow a convenient way to look at the SQFile data structure with normal Smalltalk inspectors.
This is actually NOT a recommended, for several reasons. First, these objects are meant to just be handles to an opaque data abstraction; if you started to modify the bits you could either break the abstraction, crash the VM, or become dependent on an implementation detail that could change without warning in some future release. Second, the representation is entirely platform dependent. If you want your code to run everywhere, you'd have to have variations for each platform, and you'd need to detect which platform you were running on. That's just what the Squeak VM's abstraction of the underlying OS facilities is supposed to save you from having to do.
Re:
Further background: It seems to me that there should be no real conceptual difference between an IO channel to a file, and an IO channel to a socket, or to any other external IO channel which can be opened, closed, read, or written to. Presumably these should all look like streams, and presumably we would want socket streams, file streams, and any other streams on external IO channels to behave in similar ways. The specifics of making connections to various types of external IO channels probably merit their own classes, which would know about things like SQFile and SQSocket data structures if needed. I wrote some classes to do this for files and sockets, and it all seems to work very nicely, but I still need a machine independent way to convert the file and socket data structures into Smalltalk objects, hence the question about converting integers back and forth between ByteArrays and Integers.
It seems to me that you would accomplish your goals most easily simply by building wrapper object that holds either a FileStream and Socket object. That is, you could build a class "UniversalStream" that provides buffered stream I/O to either a file or a socket. Instances of UniversalStream would have a private instance variable that was a Squeak FileStream or Socket object. There would be no reason for them to directly manipulate the data structures of the underlying VM implementation of these objects (SQFile and SQSocket).
-- John
Thanks very much for your suggestions and advice! I'm mainly just having some fun figuring out how things work at the moment. One of the things I enjoy about Squeak is being able to see the whole system all the way from the high level abstractions down to the bits and bytes. I'll try not to let my more ill-conceived experiments loose on the world ;)
Dave
On Mon, Nov 01, 1999 at 12:07:53PM -0800, John.Maloney@disney.com wrote:
Dave:
Re:
I'm trying to map a data structure (struct SQFile) in the VM to its corresponding set of objects. The data structure is available as a ByteArray on the Smalltalk side, and I was looking for a quick and dirty way to convert to ByteArray into its corresponding Integers and so forth. This would allow a convenient way to look at the SQFile data structure with normal Smalltalk inspectors.
This is actually NOT a recommended, for several reasons. First, these objects are meant to just be handles to an opaque data abstraction; if you started to modify the bits you could either break the abstraction, crash the VM, or become dependent on an implementation detail that could change without warning in some future release. Second, the representation is entirely platform dependent. If you want your code to run everywhere, you'd have to have variations for each platform, and you'd need to detect which platform you were running on. That's just what the Squeak VM's abstraction of the underlying OS facilities is supposed to save you from having to do.
Re:
Further background: It seems to me that there should be no real conceptual difference between an IO channel to a file, and an IO channel to a socket, or to any other external IO channel which can be opened, closed, read, or written to. Presumably these should all look like streams, and presumably we would want socket streams, file streams, and any other streams on external IO channels to behave in similar ways. The specifics of making connections to various types of external IO channels probably merit their own classes, which would know about things like SQFile and SQSocket data structures if needed. I wrote some classes to do this for files and sockets, and it all seems to work very nicely, but I still need a machine independent way to convert the file and socket data structures into Smalltalk objects, hence the question about converting integers back and forth between ByteArrays and Integers.
It seems to me that you would accomplish your goals most easily simply by building wrapper object that holds either a FileStream and Socket object. That is, you could build a class "UniversalStream" that provides buffered stream I/O to either a file or a socket. Instances of UniversalStream would have a private instance variable that was a Squeak FileStream or Socket object. There would be no reason for them to directly manipulate the data structures of the underlying VM implementation of these objects (SQFile and SQSocket).
-- John
Hi David--
Further background: It seems to me that there should be no real conceptual difference between an IO channel to a file, and an IO channel to a socket, or to any other external IO channel which can be opened, closed, read, or written to. Presumably these should all look like streams, and presumably we would want socket streams, file streams, and any other streams on external IO channels to behave in similar ways.
I agree; I've written a framework which includes support for streaming over any external resource (e.g., TCP and UDP sockets, serial ports, files, MIDI ports, etc.). A single small message interface applies.
It's not finished yet (not plugin-ized yet, primitives for just win32 so far), but I think the message and primitive interfaces are interesting on their own.
Further information is at http://netjam.org/correspondents.
-C
-- Craig Latta composer and computer scientist craig.latta@netjam.org www.netjam.org latta@interval.com Smalltalkers do: [:it | All with: Class, (And love: it)]
It looks like GUSI (Grand Unified Socket Interface) has finally been released. Interestingly, there's a new PThread emulation package. It might be nice to convert a fair chunk of the "external resource" code (filesystem, sockets, etc.) of the mac vm to use GUSI, for the sake of easing portability. GUSI is very freely redistributable.
Cheers, Bijan Parsia.
I got this off the MacTech (http://www.mactech.com/) site:
GUSI 2, a free[*] POSIX, sockets, and pthreads emulation library for MacOS, is now available on
ftp://sunsite.cnlab-switch.ch/software/platforms/macos/src/mw_c
The main distribution for CodeWarrior Pro 5 and MPW compilers (SC[pp] and MrC[pp]) is in GUSI_20.sit.bin, extra libraries for CodeWarrior 4 are in GUSI_20_CWPro4.sit.bin
Enjoy Matthias
-- Matthias Neeracher neeri@iis.ee.ethz.ch http://www.iis.ee.ethz.ch/~neeri
[*]
GUSI USER LICENSE
My primary objective in distributing GUSI is to have it used as widely as possible, while protecting my moral rights of authorship and limiting my exposure to liability.
Copyright (C) 1992-1999 Matthias Neeracher
Permission is granted to anyone to use this software for any purpose on any computer system, and to redistribute it freely, subject to the following restrictions:
- The author is not responsible for the consequences of use of this software,
no matter how awful, even if they arise from defects in it.
- The origin of this software must not be misrepresented, either by explicit
claim or by omission.
- Altered versions must be plainly marked as such, and must not be
misrepresented as being the original software.
While I am giving GUSI away for free, that does not mean that I don't like getting appreciation for it. If you want to do something for me beyond your obligations outlined above, you can
- Acknowledge the use of GUSI in the about box of your application and/or
your documentation.
- Send me a CD as described in
It looks like GUSI (Grand Unified Socket Interface) has finally been released.
Why not just use OpenTransport?
Please, will someone finally answer this question?
-C
-- Craig Latta composer and computer scientist craig.latta@netjam.org www.netjam.org latta@interval.com Smalltalkers do: [:it | All with: Class, (And love: it)]
Lex Spoon wrote:
---snip
But why would knowing the machine's ordering matter, unless you are doing primitives? Maybe if you post a higher-level view of what you are trying to do, someone will have a more helpful response. I tend to like the fact that I don't have to think about endianness :)
In the application I am working on, there is an endianness flag <B,b> that is used to identify the nature of a subsequent binary stream. I have not gotten to code it yet, but when I do I will need know. Yes?
John-Reed Maffeo Mesa, AZ
Hello everybody.
I found the following message on comp.lang.smalltalk.
From: Ian Upright ian@oneaccordinc.com Newsgroups: comp.lang.smalltalk Subject: Self 4.1 for Mac OS available for download Organization: One Accord Technologies Reply-To: ian@oneaccordinc.com Message-ID: UkkeOCigPDGsDggaVLsvM49wM0nG@4ax.com Date: Tue, 02 Nov 1999 02:17:24 GMT X-Complaints-To: abuse@home.net NNTP-Posting-Date: Mon, 01 Nov 1999 18:17:24 PST
For those who are curious about Self, David Ungar has made a port of Self 4.1 for Mac OS available. Apparently the new VM is easier to port to other platforms as well.
ftp://self.sunlabs.com/pub/self/Self-4.1/
Ian
One Accord Technologies ian@oneaccordinc.com
I just thought it could be interesting for this list.
Bye Adriano
--============_-1270420839==_============ Content-Type: text/plain; charset="us-ascii"
G'day all
Working recently with a number of large morphs open at the same time, I got frustrated with the difficulty in handling them, and created this little changeset to overcome the problem.
It creates a menu (press shift-cntrl and press a mouse button) which shows the top level morphs in the world, and allows you to shuffle, delete, collapse or hide them.
(A bit like the application menu on the Mac)
This leads me to a question - windows have some very handy features, like collapse and expand and the way in which the focus is changed, which are a great help when using the system. Morphs don't have those features, or have them in a less accessible way (like through halos).
Is the aim in Squeak to eventually move most of the morphs in 'applications' like Tetris/FreeCell etc into SystemWindows, or will people be using a system where there are lots of 'naked' morphs on the desktop?
Do people prefer working in SystemWindows, or using Halo and 'naked' morphs? Or is there a third option?
Does SC have a preference?
:) Russell
--============_-1270420839==_============ Content-Type: text/plain; name="DesktopMenu.4Nove634pm.cs" ; x-mac-type="54455854" ; x-mac-creator="522A6368" Content-Disposition: attachment; filename="DesktopMenu.4Nove634pm.cs" Content-Transfer-Encoding: imap_stub
0,783,2,4301,0,
--============_-1270420839==_============ Content-Type: text/plain; charset="us-ascii"
---------------------------------------- Russell Allen russell.allen@firebirdmedia.com
"No Sane man will dance. " - Cicero (106-43 B.C.)
"Show me a sane man and I will cure him for you. " - Carl Gustav Jung (1875-1961)
---------------------------------------- --============_-1270420839==_============--
Sun says that their new way of describing objects is better than classes. Now I have always thought that a "class" is, in the first place, nothing more than a naming convention.
Can anybody explain to me what they are talking about then? &BTW: do you agree with Sun, or is this just another "dot in com" talk?
Greets,
Stefan
Stefan writes:
Sun says that their new way of describing objects is better than classes. Now I have always thought that a "class" is, in the first place, nothing more than a naming convention.
Can anybody explain to me what they are talking about then? &BTW: do you agree with Sun, or is this just another "dot in com" talk?
What Self does is rather interesting - you basically clone existing objects and add your own "slots" (which roughly correspond to instance variables and methods) to the copy. You then use it to make copies, and so on. The idea of classes sort of becomes irrelevant - to create a new instance of something, you instead just find an object with the correct slots and copy it. You can also choose to make a very primitive object, make its parent an existing object, and simply override and/or add slots to do what you want.
For instance, to make a 3D Point, I'd clone a prototype 2D Point and add the extra slot for the z value. Since the original and the close share the same parent object, the 3D Point inherits all of the slots (including methods) of the original. Now, to make more 3D Points, I clone the one I just made.
Morphic, which came from Self, simulates these additional slots with the "extensions" object which hangs off of Morph. Squeak uses them most frequently to store balloon help text. The "duplicate" halo would be critical in the Self world, and so would the functionality we see as "flaps".
Frankly, Self is a very elegant system, which takes Smalltalk-like languages towards being even simpler and easier to understand. You can artificially impose a more familiar class structure if you want, as evidenced by the Smalltalk implementation in Self. Being simpler, it lends itself pretty well to interesting implementations, including runtime translation to native code. I think I saw a note from one of the Squeak luminaries (Alan?) that Self could have been Smalltalk-80's natural successor.
I would encourage people to take a look at it. I got tremendous insight into Morphic's architecture and philosophy by examining Self and reading the various white papers.
=================================================== Duane Maxwell dmaxwell (at) entrypoint.com CTO http://www.entrypoint.com EntryPoint (619) 578-8500 x226
Information contained herein is my personal opinion and not necessarily that of EntryPoint. ===================================================
squeak-dev@lists.squeakfoundation.org