Beginners

beginners@lists.squeakfoundation.org

5 participants
2858 discussions

Need ByteArray Interpreted as Base 10 UnsignedInt of 32 bits.
by Cody Sevier 08 May '24

08 May '24

Hello Squeakers, I have an algorithm for reading doom wads working in Pharo that I would like to convert to Squeak, however, I cant for the life of me figure out how to interpret a byte array of 4 bytes as an Unsigned Int. I see that a ByteArray IS an UnsignedIntCollection, but cant seem to figure out how to use it as such. Functional Pharo: binaryStream := wad binaryReadStream. wadType := (binaryStream next: 4) asString. numberOfDirectories := (binaryStream next: 4) uint32AtOffset: 0. byteOffsetToDirectories := (binaryStream next: 4) uint32AtOffset: 0. Semi Functional Squeak: binaryStream := (FileStream readOnlyFileNamed: aFileLocation) binary yourself . wadType := (binaryStream next: 4) asString. numberOfDirectories :=(binaryStream next: 4). ? byteOffsetToDirectories := (binaryStream next: 4). ? Thanks for your assistance! Kind Regards, Cody

3 5

Help with keyboard layout when typing a caret
by Ivan Reche 03 May '24

03 May '24

Hey there! Total newbie here. I'm playing with Squeak on my vacation and I've noticed that, whenever I try to type a caret (^), which I believe is core to using Smalltalk, Squeak will insert an interrogation mark (?) in its place. I believe it must be something related to keyboard layout, but I have no idea on how to troubleshoot and fix this. Here is a screenshot to show what's happening: [image: image.png] My keyboard layout works just fine on GNOME. Thanks in advance! My environment: OS: Linux (GNOME DE) Keyboard layout: Portuguese ABNT2 Squeak version: Squeak6.0-22104-64bit-202206021410-Linux-x64

6 10

Re: [squeak-dev] Re: Trigonometric function error
by lewis＠mail.msen.com 03 May '24

03 May '24

Here is my attempt to summarize what we have covered so far in this discussion: In trunk today, both sin and cos are implemented in terms of #primitiveSine, installed as <primitive: 56> and accessed by Float>>sin. There is no #primitiveCosine. The lack of #primitiveCosine in the interpreter plugins is the source of the unexpected behavior reported in the beginning of this thread, in which #sin produced plausible looking (but not meaningfully correct) results for sin of large values, but #cos produced inconsistent results. Neither sin or cos was meaningfully correct, but the cos result is inconsistent and confusing. We also have the available FloatMathPlugin, which supports many math functions including #primitiveSin and #primitiveCos. These are not currently used by the trunk image. In general terms, FloatMathPlugin favors correctness over performance. In this context, "correctness" refers to correct float rounding behavior (see Nicolas' earlier references). If we want to fix the inconsistency as originally reported in this thread, then a simple solution is to implement #primitiveCosine in the interpreter. If we want a more generally correct implementation, then we should use the FloatMathPlugin primitives (presumably with fallback to the earlier implementations). There may be legitimate tradeoffs between performance and correctness here. As far as I know, no one has yet measured the performance impact of using FloatMathPlugin for sin and cos in trunk. I am not an expert here, just trying to summarize the discussion so please correct me where I have this wrong. Dave On 2024-05-01 09:33, Nicolas Cellier wrote: > Moreover, > I recommend reading this advocacy for providing correctly rounded > library for a set of mathematical functions: > https://hal.science/hal-04474530/document > > Even if accuracy sounds useless as pointed out by Vanessa, this > analysis was carried in a certain context. > But maybe it's vital to deliver accurate cos(10**22) for implementing a > multi-precision library, who knows, > we just can't guess in which context a general purpose computing > environment such as Squeak will be used. > So if a state of the art implementation exists, then we'd better > integrate it. > > I personally wanted to replace fdlibm used by FloatMathPlugin with > CRLibm, but was stopped by the uncertain maintenance status... > > Nicolas > > Le mer. 1 mai 2024 à 11:44, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> a écrit : > > Vanessa is perfectly right. However, the accuracy of our cos > implementation starts to degrade sooner than necessary. > > If I compare with ArbitraryPrecisionFloat, which has a faithfully > rounded implementation, > the sine tend to agree, at least on my Mac: > > #(1 10 100 1000 10000) > collect: [:f | ((f asArbitraryPrecisionFloatNumBits: 53) sin - f sin) > asFloat]. > -> #(0.0 0.0 0.0 0.0 0.0) > > For the cosine, see how the accuracy is degrading: > > #(1 10 100 1000 10000) > collect: [:f | ((f asArbitraryPrecisionFloatNumBits: 53) cos - f cos) > asFloat]. > -> #(0.0 0.0 2.6645352591003757e-15 4.2521541843143495e-14 > 2.274846977456946e-13) > > Our naive implementation of cos prevents us to benefit from the efforts > and knowledge put in the libm... > I would recommend using the FloatMathPlugin in trunk. > Bonus: we would get reproducible Float operations across OSes. > For the time being, this is not the case, our primitives rely on > various libm implementations provided by the OS. > So the sine will deliver different results on Windows MacOS and Linux > for example... > > Nicolas > > Le mer. 1 mai 2024 à 01:40, Vanessa Freudenberg <vanessa(a)codefrau.net> > a écrit : > > 10**22 > At that magnitude, each float is more than 1,000,000 apart: > > So there's MANY MANY multiples of pi in between successive floats. > Asking the sine or cosine of that is nonsensical. > > Vanessa > > On Tue, Apr 30, 2024 at 14:24 <lewis(a)mail.msen.com> wrote: > > On 2024-04-30 10:45, dgray(a)iesl.forth.gr wrote: > When I start messing about with a new language I have a few corner > cases I try out just to see what answers I expect. > For Squeak this has been OK except for cos. > The two numbers I check are totally away from those I routinely use but > are stress tests. > (10**22) sin. -0.8522008497671888 "which is correct" > (10**22) cos. -0.8522008497671888 "gives the same as sin which is > suspicious" > (2**120) sin. 0.377820109360752 "Also correct" > (2**120) cos. 0.377820109360752 "Also the same as the sin case. I > expect -0.9258790228548379" > _______________________________________________ > Beginners mailing list -- beginners(a)lists.squeakfoundation.org > To unsubscribe send an email to > beginners-leave(a)lists.squeakfoundation.org > > Hello and welcome to Squeak! Thank you very much for reporting this, > and congratulations on a very nice bug catch. > > I think that you have identified an issue related to floating point > data conversions. I am copying the main squeak-dev list on this, where > I anticipate some lively follow up discussion. > > For follow up on squeak-dev: The cosine logic for a large integer > involves first converting the integer to a Float, then sending > Float>>cos, which answers (self + Halfpi) sin. If the receiver is a > very large floating point value, then self + Halfpi is the same as > self, and we effectively calculate sin where cos was expected. At least > I think that's what's happening, I'm sure someone will correct me > quickly if I have it wrong :-) > > Dave

1 0

Trigonometric function error
by dgray＠iesl.forth.gr 02 May '24

02 May '24

When I start messing about with a new language I have a few corner cases I try out just to see what answers I expect. For Squeak this has been OK except for cos. The two numbers I check are totally away from those I routinely use but are stress tests. (10**22) sin. -0.8522008497671888 "which is correct" (10**22) cos. -0.8522008497671888 "gives the same as sin which is suspicious" (2**120) sin. 0.377820109360752 "Also correct" (2**120) cos. 0.377820109360752 "Also the same as the sin case. I expect -0.9258790228548379"

2 2

Squeak/Morphic As A Candidate for a Doom Style Game Engine, Unrealistic?
by Cody Sevier 07 Mar '24

07 Mar '24

Hello Everyone, Firstly, this is my first message here, so please correct my etiquette if it is not appropriate, or if I am mailing the wrong list. I discovered smalltalk a few months back and i've been growing excited with use. I read through a few books like the squeak by example book and others. I now think it's time to take on a project of substance to really gain some experience. I was really impressed with the multimedia/liveness of squeak and the stepping system of morphic. I thought to myself that this would be a perfect environment for some game development and thats where my current professional skills are being used. Cursory research showed others with games projects, even some with 3d to my surprise. I suspect those 3d engines are using the FFI to bind to c libs to achieve acceptable performance. My desire would be to build a 2.5d rendering system inspired by the doom engine. I figured it might be a better candidate performance wise then a full 3d engine and since its a software render, entirely self contained. (im not interested in external bindings yet.) However, I discovered the FPSMorph when exploring and to my dismay saw my system running at 47 fps on average simply idling. My specs are pretty good, Intel© Core™ i7-8705G CPU @ 3.10GHz × 4. So I thought surely this is a stepping concern, perhaps they have limited it. I changed the update interval and was guaranteed no additional frames. Im going to dig in further to see if implementation details are the issue, but thought it might be a good idea to consult the experts in tandem. So, is morphic really that slow for everyone else? Im concerned that if I take on such a project it may never actually be usable beyond learning. Would anyone willing to share their experience doing games? Perhaps maybe bypassing morphic and using direct Form + BitBlt would be faster? Any advice, experience or wisdom would be greatly appreciated. Im more then okay with being told this wont work etc. Sorry for the long mail and thanks for the great system! Kind Regards, Cody Sevier

2 2

DKIM signing fixed
by Taeumel, Marcel 09 Feb '24

09 Feb '24

Hi all -- Our admin volunteer Yannis (CC) fixed DKIM signing. Hooraaaay! Hopefully, more mail servers will now accept our list traffic again. :-) Best, Marcel

1 0

how to scan files and folders
by ruivianapereira＠gmail.com 29 Oct '23

29 Oct '23

I'm not a programmer of any kind or language; I'm an amateur. I have a personal digital library with thousands of documents, which are useless unless I manage to classify them. I thought it would be an easy task with Squeak, since it is a quite simple problem, but I'm lacking some solutions, as a beginner. My general cenario: I made a class, lets call it card, to hold information about each work, each author, their location on disk and the relations between authors and works: Object>>#Card (instance var : name, location, notes, tags ... ) >>Author >> Work Object>>#MyLibrary (instance var : authors <aCollection>, works <aCollection>, myLibraryBase <aPath?>) Than I initialize #MyLibrary instances with a UIManager directoryChooser to establish from the begining a reference to the directory where all the relevant files are. But, because it is thousands of files, I would need an automatic method to «scan» all the relevant files in the directories and subdirectories. Meaning: the method should make a collection of all the files, recursively in subdirectories, and for each one it should create a card. And that's where I got stuck: how do I scan recursively the subdirectories? Most of the new tools are quite confusing for me, namely classes and tools to deal with files. Can anyone point me in the wright direction, please? Thanks

4 3

Squeak Books
by Andrew Goh 22 Oct '23

22 Oct '23

Hi Squeak Foundation, I believe the Squeak language is similar to Visual Basic and Delphi in that it is a event-oriented programming language However, I notice that there is a shortfall in the number of Squeak books when compared to the Pharo language. Perhaps, more tutorials should be written on exploiting Squeak. Regards, --- Andrew Goh

2 1

FreeBSD VM
by David Gray 31 Aug '23

31 Aug '23

Finally managed to carve out some time to try this again. It looks like a few people have been looking into to this in the meantime (thanks a lot) and even though I can’t follow exactly what has been changed etc I can report that when I clone the latest opensmalltalk-vm I can get a working system. I can open a workspace and Try a few tests with no crashes: (10**22) sin -0.8522008497671888 fib := [ :n | n > 2 ifTrue: [(fib value: n-2) + (fib value: n-1)] ifFalse: [1]]. "closure on block variable" fib value: 30. 832040 | x t | x := #(30 36 42 54 66 69). [1 to: 6 do: [:a | Transcript show: (Time millisecondsToRun: [t := (fib value: (x at: a))]). Transcript show: ' '. Transcript show: t. Transcript cr. ] ] forkAt: Processor userBackgroundPriority. 1081502 / 1000 / 60.0 18.025033333333333 1+2+3+4+5+6+7+8+9+10 55 Time durationToRun: [fib value: 42] 0:00:00:03.406797 2+2 4 I installed a clean FreeBSD 13 release. I used a minimal install for org and a simple wm: openbox Then did a git clone of: https://github.com/OpenSmalltalk/opensmalltalk-vm <https://github.com/OpenSmalltalk/opensmalltalk-vm> I changed the shell to bash then did: ./scripts/updateSCCSVersions Then I changed to opensmalltalk-vm/building/linux64x64/squeak.cog.spur/build Ran: ./mvm Down loaded the latest Squeak6.0-22104-64bit.image & .changes and renamed them in the dir to squeak.image & squeak.changes. I copied the SqueakV60.sources here too. ./squeak ran. I accepted all the defaults for configure & then installed system updates, FFI, and OS system. And that’s it.

6 6

Question re parsing in early Smalltalks
by Hugo Saavedra 30 Aug '23

30 Aug '23

Hi there, I've been writing an evaluator for a toy Smalltalk-like language, and reading the paper "The Evolution of Smalltalk" by Dan Ingalls which discusses the history from ST-72 to Squeak to get a better understanding of how STs worked under the hood. My understanding from this paper (mainly, pages 4-6) and others is that in early implementations, objects were responsible for the evaluation of their own messages in a fairly low level sense That is, ST-72 programs were first parsed in a sort of pre-processing step -- in such a way where objects could be initialized and differentiated from the tokens representing their messages. Then the messages as raw token streams were parsed into ASTs by the objects themselves, which then interpreted them. Is this actually how it worked? It makes sense to me that it would work in this way -- I was thinking when writing a parser for my toy Smalltalk that the parser should probably be fairly ignorant about the nature of the messages it parses, outside of being able to distinguish selectors and arguments, and binary messages vs keyword vs unary messages. In particular it probably does not know anything about precedence rules, since that would violate encapsulation and modularity -- e.g. in 3 + 2*4, it should be whatever method is invoked by the + selector that determines what happens to the tokens 2*3 rather than the parser -- i.e. whether we add 2 first and then multiply the sum by 3, or perform the multiplication and then add the product as in standard arithmetic. But it also seems like this would force developers to mix tedious parsing code with domain code, which feels kind of messy. I would really appreciate any clarification on this -- apologies if this is the wrong list for this sort of question, I'm very new to the community Thank you

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

Beginners