Vm-dev May 2020

vm-dev@lists.squeakfoundation.org

39 participants
130 discussions

[OpenSmalltalk/opensmalltalk-vm] 60973e: Upgrade win32 HostWindowPlugin support to TerfVM s...
by Eliot Miranda 17 May '20

17 May '20

Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 60973ef04730d9a34429c828cfc21cc3d29f4026 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/60973ef04730d9a344… Author: Eliot Miranda <eliot.miranda(a)gmail.com> Date: 2020-05-16 (Sat, 16 May 2020) Changed paths: M platforms/win32/plugins/HostWindowPlugin/sqWin32HostWindowPlugin.c Log Message: ----------- Upgrade win32 HostWindowPlugin support to TerfVM specs, in line with the iOS plaform.

1 0

[OpenSmalltalk/opensmalltalk-vm] 027e35: Morph a few win32 files from CRLF/dos to LF/unix l...
by Eliot Miranda 17 May '20

17 May '20

Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 027e3593d2c1082b7e50bb3e28481586c5732cac https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/027e3593d2c1082b7e… Author: Eliot Miranda <eliot.miranda(a)gmail.com> Date: 2020-05-16 (Sat, 16 May 2020) Changed paths: M platforms/win32/plugins/CameraPlugin/winCameraOps.cpp M platforms/win32/plugins/CroquetPlugin/sqWin32CroquetPlugin.c M platforms/win32/plugins/FT2Plugin/ft2build.h M platforms/win32/plugins/FilePlugin/sqWin32File.h M platforms/win32/plugins/FloatMathPlugin/Makefile M platforms/win32/plugins/FloatMathPlugin/Makefile.plugin M platforms/win32/plugins/FloatMathPlugin/Makefile.win32 M platforms/win32/plugins/FontPlugin/sqWin32FontPlugin.c M platforms/win32/plugins/HostWindowPlugin/sqWin32HostWindowPlugin.c M platforms/win32/plugins/LocalePlugin/sqWin32Locale.c M platforms/win32/plugins/SqueakSSL/sqWin32SSL.c M platforms/win32/vm/config.h M platforms/win32/vm/sqWin32Directory.c M platforms/win32/vm/sqWin32DnsInfo.c M platforms/win32/vm/sqWin32HandleTable.h M platforms/win32/vm/version.c Log Message: ----------- Morph a few win32 files from CRLF/dos to LF/unix lineendings. [ci skip]

1 0

Re: [Vm-dev] [Pharo-dev] Squeak and Pharo speed differences
by Shaping 16 May '20

16 May '20

Why can’t the OSVM be a single, unforked, maxed-out VM with all the best and fastest features working in Squeak and Pharo? Why did the split happen? In very general terms, the fork was due to their being Group A wanting to go one direction and Group B wanting to go in a different direction. i.e.... B says "We want to do X". A says "We don't want to do X." B says "We really want to do X." A says "Definitely no." B says "We really want to do X and actually we're doing it over here." Lol Thanks for the explanation. That’s more or less what I thought. But can’t the differences be setup at config-your-environ time instead of build time, when the task is heavier and slower? In essence, Squeak considered backward compatibility of prime importance including the code of some applications that had become entangled in the main code base. Pharo wanted to "clean the code" by disentangling and stripping those parts. I like disentangling and modularizing. I suppose this is a universal like. They also wanted to move to a reproducible-build-system where each change "bootstrapped" a nightly image from an empty file, I like this too. whereas Squeak continues to use a "continuous evolution" model. Don’t both groups want the automatic building and testing the Consortium is talking about recently? I’m not sure I understand how “continuous evolution” works. Sounds like there is lots of wiggle room in that idea. Don’t we need some structure? We seem to be getting that in Pharo. I’m not sure about Squeak. The GUI tools/menus still feel hodgepodge (much nicer, but still not well organized) 16 years later. I used it between 2002 to 2004, and then again just a few days ago. I like the faster debugger and the flat GUIs, but I don’t need Morphic to have those dev-tool GUIs. I’d prefer to rework the GUIs with Spec2/GTK3, and keep the flat, clean, button-packed look with some improvements (like the new Spec2 selection highlighting pattern, which is very nice). The rest of Squeak seems messy. I do very much like the technical, concrete feel of Squeak’s details about the VM. That reminds me of old times and why I got involved in computers, and it supports my current interest in VM parallelization. Those VM details need a somewhat different shape/presentation. There is a beauty in Squeak, but the eviron still feels a bit rough. For example, why aren’t all those preferences in a tree where you can actually find things because they are categorized. It’s a big list. That seems very strange in 2020. Why don’t Squeak folks borrow the Pharo Settings GUI idea, and implement that in Morphic, as they like? I thought more would have happened in the Squeak GUI in 16 years, but I’ve not seen all of 5.3 yet. I’m still poking around. I suppose most of the improvements are in the VM, which I imagine absorbs most of the group’s energy. And there are more reasons I probably not aware of. Here is the Pharo Vision document circa 2012 which inspired me https://hal.inria.fr/hal-01879346/document Thank you. I will read it. Is the Consortium updating that doc? There was a doc recently from Stef that looks like it belongs in there, merged somehow. It looks like a bad use of energy in a community that is small and needs to use its human resources efficiently. Trying to go one way and dealing with continual pushback and conflict around that is also bad energy. Agreed. I don’t understand the pushback because I don’t understand Squeak folks’ objection to rigorous, systematic, automatic testing and disentangling/modularizing of frameworks. They are probably fine with all that. Do Squeak folks have a document that defines “continuous development.” I know that VM testing is automated. I don’t see how the objectives are so different, at least on the automation front. Everyone seems to agree that CI is good. I want to help, but need to port first from VW, and I’m trying to choose Squeak or Pharo. Both have speed problems. Squeak has fewer, but Pharo could be much faster with broad use of Spec2. Would reintegrating Squeak and Pharo development make more sense? I think that is not likely. Both continue to have different goals. And a significant area where they are likely to continue to diverge is the graphics. Squeak is likely(?) to stay with Morphic a long while Pharo intends to dump Morphic. I never liked the halo thing. It’s okay. It seemed/seems too busy and distracting. I think Morphic and the “too many cooks” problem is why I broke off in 2004. If we are fully modular, and you love Morphic, and want to live there mentally and visually, all the time, then load the Morphic package into the new universal OpenSmalltalk. Have all your GUIs built with Morphic. Have cute little morphs stuck here and there. Knock yourself out. Don’t like Morphic? Don’t think it’s cute? Load the more business-like-but-not-boring Spec2. I don’t see an insurmountable technical problem here. This is one of the reasons that Spec was created - to be independence layer. IIUC in Pharo 9 Spec is already working on top of a GTK3 backend. Yes, the Spec2 Launcher is inspiringly snappy, modulo the text-selection slowness problem, which is everywhere in Pharo and Squeak. I’ve mentioned this a few times recently—of all the goofy things to prevent a port from VW…..Okay, that and Pharo’s slow debugger. Two things keep me out of Pharo/Squeak. I don’t love VW. I tolerate it really well. That’s different. :) wrt the VM, Pharo want to remove all native-windowing from the VM, so that window opening is controlled from the Image via FFI rather than the VM. I agree with the objective. This conflicts with Squeak's backward comparability goals. Okay, this is the real problem. So there is a ton of old Squeak code that no one is willing to rework in order to be compatible with the new vision for native-windowing independence. Perhaps someone can give more details on that old code. I suppose many Squeak folks bemoan all the extra work needed for a recoding. Is this still really an issue? Maybe very little of that old code is still being used in business-critical ways. The need for a recoding may not be the big issue it once was. This change would effectively create more devs willing to work on any problem. This change would also prevent fracturing of feature-sets across the two Smalltalks from happening in the first place. I personally had the inspiration that Squeak might be based off the Pharo Headless Bootstrap, but in the end I didn't find the time to push this further. That’s a very good idea. Why don’t all the Squeak folks work on it? Are you the only one pushing for this? Squeak and Pharo GUI styles are different. So be it. Can’t the GUI frameworks and conventions be separated in the same image, and configured as desired in GUI sections of Settings? Pharo currently can use both Morphic and GTK3 for its GUI backend. Possibly the GTK3 backend would provide some speed benefit (??) It’s a good question. Is the core Morphic issue whether GTK3 can render non-rectangular shapes efficiently? There’s a lot of that in Morphic. I suppose it’s the main concern. Even if Morphic relies on special drawing primitives, they can go in a lib and be accessed via FFI. Shaping

2 1

Squeak and Pharo speed differences
by Shaping 16 May '20

16 May '20

Hi all. Squeak 5.3: Time millisecondsToRun: [ 100000 factorial ] 6250 Pharo 8: Time millisecondsToRun: [ 100000 factorial ] 7736 Why the difference? Squeak 5.3 release notes describe arithmetic improvements. Nice. I crunch very big numbers, and these improvements therefore have value. Why would they not be included in OSVM (forked or not) and the basic class-set for both Squeak and Pharo? Playing with Squeak 5.3, I’ve noticed that the GUI is snappier. Browser ergonomics are better too (for me at least), but that can be fixed/tuned in either environ to suit the developer. (Still that’s some work I prefer not to do.) Pharo GUIs are now generally slower, except for the Launcher, which is delightfully quick because it is written in Spec2. I presume that all Pharo GUIs will eventually (ETA?) be written in Spec2 and that Pharo will then be quick in all its GUIs. The obvious question is: Will Squeak be improving GUI look/behavior and speed with Spec2? If not, can I load Spec2 into Squeak so that I can do new GUI work there? Both Squeak and Pharo have slow text selection. Pick any word in any pane, and double click it to select it. When I do this, I sense a 75 to 100 ms latency between the end of the double click and the selection highlight appearing on the word. I thought I’d entered a wormhole. So I did the same experiment in VW 8.3.2, VS Code, and Notepad, and all three showed undetectable latencies. This matters to me. I’m trying to port from VW to Pharo or Squeak (for a really long time now), and can’t push myself past the text-selection delay problem. Can text-selection speed be improved to the level of VW’s? Can someone sketch the algo used and/or point me to the right class/methods. The Squeak debugging experience step-to-step is much quicker. The latencies in Pharo after button- release are very long. I estimate 100 to 150 ms. That’s too long for me to work productively. I lose my mental thread with many of those delays, and have to restart the thought. It’s a serious problem, caused mostly by acclimation to no detectable latency for many years (Dolphin and VW have quick GUIs). Is speeding up the Pharo debugger with Spec2 a priority? I can’t think of a better GUI-related priority for Pharo. Not speed-related: - How can I load additional fonts into Squeak? Pharo does this with the font dialog’s Update button. - Where in the Squeak and Pharo images can I change mouse-selection behavior to be leading-edge? Some of the Squeak panes have this; others don’t. I want leading-edge action in all panes, and wish the feature were in Preferences/Settings. Shaping

2 2

Fwd: [Pharo-dev] Squeak and Pharo speed differences
by Eliot Miranda 15 May '20

15 May '20

> From: Eliot Miranda <eliot.miranda(a)gmail.com> > Date: May 15, 2020 at 7:26:13 AM PDT > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Subject: Re: [Pharo-dev] Squeak and Pharo speed differences > > Hi Shaping, > > _,,,^..^,,,_ (phone) > >>> On May 15, 2020, at 2:18 AM, Shaping <shaping(a)uurda.org> wrote: >>> >> >> Arithmetic changes proposed in Squeak have no relationships to VM. >> >> The question below is about both the VM and a common basic class-set. Math-related classes/methods are assumed to be part of that common class-set. Why is that not so? >> >> Shaping >> >> On Fri, May 15, 2020 at 2:09 PM Shaping <shaping(a)uurda.org> wrote: >> There is an issue about incorporating Squeak arithmetic changes in Pharo: >> https://github.com/pharo-project/pharo/issues/3322 >> >> I start to understand what could be done and could not find time to do the changes. >> You are welcome if you want to help. >> >> >> Arithmetic speed is important if most of one’s work is math and modeling. >> >> I want to help, but need to port first from VW, and I’m trying to choose Squeak or Pharo. Both have speed problems. Squeak has fewer, but Pharo could be much faster with broad use of Spec2. > > Generally, comparing VisualWorks to either Squeak or Pharo or both, what are the most pressing speed problems? Where is VisualWorks significantly faster than either Squeak or Pharo? Specifically which VisualWorks VM or lower level facilities are much faster than the Cog VM? Do you have benchmarks? > >> Would reintegrating Squeak and Pharo development make more sense? >> >> This change would effectively create more devs willing to work on any problem. This change would also prevent fracturing of feature-sets across the two Smalltalks from happening in the first place. >> >> Why can’t the OSVM be a single, unforked, maxed-out VM with all the best and fastest features working in Squeak and Pharo? Why did the split happen? It looks like a bad use of energy in a community that is small and needs to use its human resources efficiently. >> >> Squeak and Pharo GUI styles are different. So be it. Can’t the GUI frameworks and conventions be separated in the same image, and configured as desired in GUI sections of Settings? >> >> >> Shaping >> >> >> On Fri, May 15, 2020 at 12:48 PM Shaping <shaping(a)uurda.org> wrote: >> Hi all. >> >> >> Squeak 5.3: >> Time millisecondsToRun: [ 100000 factorial ] 6250 >> >> Pharo 8: >> Time millisecondsToRun: [ 100000 factorial ] 7736 >> >> Why the difference? >> >> Squeak 5.3 release notes describe arithmetic improvements. Nice. I crunch very big numbers, and these improvements therefore have value. Why would they not be included in OSVM (forked or not) and the basic class-set for both Squeak and Pharo? >> >> Playing with Squeak 5.3, I’ve noticed that the GUI is snappier. Browser ergonomics are better too (for me at least), but that can be fixed/tuned in either environ to suit the developer. (Still that’s some work I prefer not to do.) Pharo GUIs are now generally slower, except for the Launcher, which is delightfully quick because it is written in Spec2. I presume that all Pharo GUIs will eventually (ETA?) be written in Spec2 and that Pharo will then be quick in all its GUIs. The obvious question is: Will Squeak be improving GUI look/behavior and speed with Spec2? If not, can I load Spec2 into Squeak so that I can do new GUI work there? >> >> Both Squeak and Pharo have slow text selection. Pick any word in any pane, and double click it to select it. When I do this, I sense a 75 to 100 ms latency between the end of the double click and the selection highlight appearing on the word. I thought I’d entered a wormhole. So I did the same experiment in VW 8.3.2, VS Code, and Notepad, and all three showed undetectable latencies. This matters to me. I’m trying to port from VW to Pharo or Squeak (for a really long time now), and can’t push myself past the text-selection delay problem. Can text-selection speed be improved to the level of VW’s? Can someone sketch the algo used and/or point me to the right class/methods. >> >> The Squeak debugging experience step-to-step is much quicker. The latencies in Pharo after button- release are very long. I estimate 100 to 150 ms. That’s too long for me to work productively. I lose my mental thread with many of those delays, and have to restart the thought. It’s a serious problem, caused mostly by acclimation to no detectable latency for many years (Dolphin and VW have quick GUIs). Is speeding up the Pharo debugger with Spec2 a priority? I can’t think of a better GUI-related priority for Pharo. >> >> >> Not speed-related: >> >> - How can I load additional fonts into Squeak? Pharo does this with the font dialog’s Update button. >> >> - Where in the Squeak and Pharo images can I change mouse-selection behavior to be leading-edge? Some of the Squeak panes have this; others don’t. I want leading-edge action in all panes, and wish the feature were in Preferences/Settings. >> >> >> >> Shaping >> >> >> >> >> >> >> >> >> >> >> >> -- >> Serge Stinckwic >> h >> https://twitter.com/SergeStinckwich >> >> >> >> -- >> Serge Stinckwic >> h >> https://twitter.com/SergeStinckwich >>

1 0

VM Maker: VMMaker.oscog-eem.2755.mcz
by commits＠source.squeak.org 14 May '20

14 May '20

Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.2755.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.2755 Author: eem Time: 14 May 2020, 1:54:08.600302 pm UUID: 804700d1-cc28-4b4f-b27d-091069478525 Ancestors: VMMaker.oscog-dtl.2754 Better document callPrimitiveBytecode. =============== Diff against VMMaker.oscog-dtl.2754 =============== Item was changed: ----- Method: StackInterpreter>>callPrimitiveBytecode (in category 'miscellaneous bytecodes') ----- callPrimitiveBytecode + "SistaV1: ** 248 (2) 11111000 iiiiiiii mssjjjjj Call Primitive #iiiiiiii + (jjjjj * 256) + m=1 means inlined primitive, no hard return after execution. + ss defines the unsafe operation set used to encode the operations. + (ss = 0 means sista unsafe operations, ss = 01 means lowcode operations, other numbers are as yet used) + V3/Spur: 139 10001011 i i i i i i i i jjjjjjjj Call Primitive #iiiiiiii + (jjjjjjjj * 256) + V4: 249 11111001 i i i i i i i i jjjjjjjj Call Primitive #iiiiiiii + (jjjjjjjj * 256)" + - "V4: 249 11111001 i i i i i i i i jjjjjjjj Call Primitive #iiiiiiii + (jjjjjjjj * 256) - SistaV1: 248 11111000 iiiiiiii mjjjjjjj Call Primitive #iiiiiiii + (jjjjjjj * 256) m=1 means inlined primitive, no hard return after execution. - V3/Spur: 139 10001011 i i i i i i i i jjjjjjjj Call Primitive #iiiiiiii + (jjjjjjjj * 256)" "Note that we simply skip a callPrimitiveBytecode at the start of a method that contains a primitive. This because methods like Context(Part)>>reset have to be updated to skip the callPrimtiive bytecode otherwise." SistaVM ifTrue: [| byte1 byte2 prim primSet header | byte1 := self fetchByte. byte2 := self fetchByte. self fetchNextBytecode. byte2 < 128 ifTrue: [header := objectMemory methodHeaderOf: method. ((self methodHeaderHasPrimitive: header) and: [localIP asUnsignedInteger = (self initialIPForHeader: header method: method) + (self sizeOfCallPrimitiveBytecode: header)]) ifTrue: [^self]. localIP := localIP - 3. ^self respondToUnknownBytecode]. + prim := byte2 - 128 << 8 + byte1. primSet := prim >> 13 bitAnd: 3. prim := prim bitAnd: 8191. primSet = 0 ifTrue: [^self sistaInlinePrimitive: prim]. + LowcodeVM ifTrue: + [primSet = 1 ifTrue: + [prim < 1000 ifTrue: - LowcodeVM ifTrue: [ - primSet = 1 ifTrue: [ - prim < 1000 ifTrue: [^self lowcodeNullaryInlinePrimitive: prim]. prim < 2000 ifTrue: [^self lowcodeUnaryInlinePrimitive: prim - 1000]. prim < 3000 ifTrue: [^self lowcodeBinaryInlinePrimitive: prim - 2000]. prim < 4000 ifTrue: + [^self lowcodeTrinaryInlinePrimitive: prim - 3000]]]. - [^self lowcodeTrinaryInlinePrimitive: prim - 3000]. - ]. - ]. + localIP := localIP - 3] - localIP := localIP - 3. - ^self respondToUnknownBytecode] ifFalse: [| header | header := objectMemory methodHeaderOf: method. ((self methodHeaderHasPrimitive: header) + and: [localIP asInteger = (self initialIPForHeader: header method: method)]) ifTrue: + [localIP := localIP + (self sizeOfCallPrimitiveBytecode: header) - 1. + ^self fetchNextBytecode]]. + + ^self respondToUnknownBytecode! - and: [localIP asInteger = (self initialIPForHeader: header method: method)]) - ifTrue: - [localIP := localIP + (self sizeOfCallPrimitiveBytecode: header) - 1. - ^self fetchNextBytecode] - ifFalse: - [^self respondToUnknownBytecode]]! Item was changed: ----- Method: StackToRegisterMappingCogit>>genCallPrimitiveBytecode (in category 'bytecode generators') ----- genCallPrimitiveBytecode + "SistaV1: ** 248 (2) 11111000 iiiiiiii mssjjjjj Call Primitive #iiiiiiii + (jjjjj * 256) + m=1 means inlined primitive, no hard return after execution. + ss defines the unsafe operation set used to encode the operations. + (ss = 0 means sista unsafe operations, ss = 01 means lowcode operations, other numbers are as yet used). + See SistaCogit genCallPrimitiveBytecode, EncoderForSistaV1's class comment and StackInterpreter>>#callPrimitiveBytecode for more information." - "SistaV1: 248 11111000 iiiiiiii mjjjjjjj Call Primitive #iiiiiiii + (jjjjjjj * 256) m=1 means inlined primitive, no hard return after execution. - See EncoderForSistaV1's class comment and StackInterpreter>>#inlinePrimitiveBytecode:" | prim primSet | byte2 < 128 ifTrue: [^bytecodePC = initialPC ifTrue: [0] ifFalse: [EncounteredUnknownBytecode]]. prim := byte2 - 128 << 8 + byte1. primSet := prim >> 13 bitAnd: 3. prim := prim bitAnd: 8191. + LowcodeVM ifTrue: + [primSet = 1 ifTrue: + [prim < 1000 ifTrue: + [^self genLowcodeNullaryInlinePrimitive: prim]. - LowcodeVM - ifTrue: - [ - primSet = 1 ifTrue: [ - prim < 1000 ifTrue: - [^self genLowcodeNullaryInlinePrimitive: prim]. + prim < 2000 ifTrue: + [^self genLowcodeUnaryInlinePrimitive: prim - 1000]. + + prim < 3000 ifTrue: + [^ self genLowcodeBinaryInlinePrimitive: prim - 2000]. - prim < 2000 ifTrue: - [^self genLowcodeUnaryInlinePrimitive: prim - 1000]. - - prim < 3000 ifTrue: - [^ self genLowcodeBinaryInlinePrimitive: prim - 2000]. + prim < 4000 ifTrue: + [^self genLowcodeTrinaryInlinePrimitive: prim - 3000]]]. - prim < 4000 ifTrue: - [^self genLowcodeTrinaryInlinePrimitive: prim - 3000]. - ] - ]. ^EncounteredUnknownBytecode!

1 0

VM Maker: BytecodeSets.spur-eem.80.mcz
by commits＠source.squeak.org 14 May '20

14 May '20

Eliot Miranda uploaded a new version of BytecodeSets to project VM Maker: http://source.squeak.org/VMMaker/BytecodeSets.spur-eem.80.mcz ==================== Summary ==================== Name: BytecodeSets.spur-eem.80 Author: eem Time: 14 May 2020, 1:47:26.034897 pm UUID: 75c6423a-ca63-4584-a5d9-2e0d4fc3bd7d Ancestors: BytecodeSets.spur-eem.79 Better document InstructionPrinter>>callInlinePrimitive: =============== Diff against BytecodeSets.spur-eem.79 =============== Item was changed: ----- Method: InstructionPrinter>>callInlinePrimitive: (in category '*BytecodeSets-instruction decoding') ----- callInlinePrimitive: index + "Print the callInlinePrimitive: bytecode. This is the m = 1, ss = 0 case in SistaV1: ** 248 below. + + SistaV1: ** 248 (2) 11111000 iiiiiiii mssjjjjj Call Primitive #iiiiiiii + (jjjjj * 256) + m=1 means inlined primitive, no hard return after execution. + ss defines the unsafe operation set used to encode the operations. + (ss = 0 means sista unsafe operations, ss = 01 means lowcode operations, other numbers are as yet used) + V3/Spur: 139 10001011 i i i i i i i i jjjjjjjj Call Primitive #iiiiiiii + (jjjjjjjj * 256)" + - "Print the callInlinePrimitive." self print: 'callInlinePrimitive: ' , ((#((1000 ' class') (1001 ' pointer numSlots') (1002 ' pointer basicSize') (1003 ' byte8Type format numBytes') (1004 ' short16Type format numSho') (1005 ' word32Type format numWord') (1006 ' doubleWord64Type format n') (1010 ' ensure number of bytes available') (1011 ' fixed pointer basicNew') (1020 ' identityHash (non-immediate, non-Behavior, has hash)') (1021 ' identityHash (SmallInteger)') (1022 ' identityHash (Character)') (1023 ' identityHash (SmallFloat64)') (1024 ' identityHash (Behavior, has hash?)') (1030 ' immediateAsInteger (Character)') (1031 ' immediateAsInteger (SmallFloat64)') (2000 ' SmallInteger #+') (2001 ' SmallInteger #-') (2002 ' SmallInteger #*') (2003 ' SmallInteger #/') (2004 ' SmallInteger #//') (2005 ' SmallInteger #\\') (2006 ' SmallInteger #quo:') (2011 ' Variable-sized pointers new (new:). Array, etc') (2012 ' Variable-sized byte new (new:). ByteArray, ByteString, etc') (2013 ' Variable-sized 16-bit new (new:). DoubleByteArray, etc') (2014 ' Variable-sized 32-bit new (new:). Bitmap, FloatArray, etc') (2015 ' Variable-sized 64-bit new (new:). DoubleWordArray, etc') (2016 ' SmallInteger #bitAnd:') (2017 ' SmallInteger #bitOr:') (2018 ' SmallInteger #bitXor:') (2019 ' SmallInteger #bitShiftLeft:') (2019 ' SmallInteger #bitShiftRight:') (2032 ' SmallInteger #>') (2033 ' SmallInteger #<') (2034 ' SmallInteger #>=') (2035 ' SmallInteger #<=') (2036 ' SmallInteger #=') (2037 ' SmallInteger #~=') (2064 ' Pointer Object>>at:') (2065 ' Byte Object>>at:') (2066 ' 16-bit Word Object>>at:') (2067 ' Word Object>>at:') (2068 ' DoubleWord Object>>at:') (2069 ' QuadWord Object>>at:') (3000 ' Pointer Object>>at:put:') (3001 ' Byte Object>>at:put:') (3002 ' Word Object>>at:put:') (3003 ' DoubleWord Object>>at:put') (3004 ' QuadWord Object>>at:put:')) detect: [:tuple| tuple first = index] ifNone: [{index printString}]) last)!

1 0

Question | Bump min support from WinXP to Win8
by Marcel Taeumel 14 May '20

14 May '20

Hi all! I have opened a pull request: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/499 [https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/499] The idea of bumping the version from Windows XP (0x0501) to Windows 8 (0x0602) came from the rather crude attempt to check for "if API exists" in sqWin32Main.c: typedef BOOL(WINAPI *pfnGetFileInformationByHandleEx)(...); static pfnGet[...]HandleEx pGet[...]HandleEx = NULL; if (!pGet[...]HandleEx) { ... GetProcAddress(GetModuleHandle(TEXT("kernel32.dll")) ... if (!pGet[...]HandleEx) return -1; } ... (See https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-getfi… [https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-getfi…]) Also, there are some definitions copied over from newer header files. Just take a look that those "#if (WINVER < 0x0400)" and similar. Microsoft has long ended the support for Windows XP. The next in line look similiar: Windows Vista, Windows 7. Support has ended there, too. We could bump further but Windows 8 looks like a fair improvement in reliability and robustness comparing to its predecessors. And the last update for Windows 8 was only 8 years ago. Not even a decade. :-) Best, Marcel

6 8

[OpenSmalltalk/opensmalltalk-vm] Removes use of WCE_PREFERENCES (#502)
by Marcel Taeumel 13 May '20

13 May '20

... which was part of the recently removed Windows CE support You can view, comment on, or merge this pull request online at: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/502 -- Commit Summary -- * Removes use of WCE_PREFERENCES, which was part of the Windows CE support. -- File Changes -- M platforms/win32/vm/sqWin32Prefs.c (7) -- Patch Links -- https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/502.patch https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/502.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/502

2 1

[OpenSmalltalk/opensmalltalk-vm] 3b594e: Removes use of WCE_PREFERENCES, which was part of ...
by Nicolas Cellier 13 May '20

13 May '20

Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 3b594e1ef865de1b7b9639c9a3992f4f822eb50d https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/3b594e1ef865de1b7b… Author: Marcel Taeumel <marcel.taeumel(a)hpi.de> Date: 2020-05-13 (Wed, 13 May 2020) Changed paths: M platforms/win32/vm/sqWin32Prefs.c Log Message: ----------- Removes use of WCE_PREFERENCES, which was part of the Windows CE support. Commit: aa7e03a916a7a52056cc4d6989fd5cac63c36d7e https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/aa7e03a916a7a52056… Author: Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> Date: 2020-05-13 (Wed, 13 May 2020) Changed paths: M platforms/win32/vm/sqWin32Prefs.c Log Message: ----------- Merge pull request #502 from marceltaeumel/marceltaeumel/patch-2 Removes use of WCE_PREFERENCES Compare: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/c1cdd0d88a1b...aa…

1 0

← Newer
1
...
5
6
7
8
9
10
11
12
13
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev May 2020