At the latest board meeting we got to discussing the relative quietness of the squeak list(s) recently. We were wondering what you folks out there are doing with Squeak, what you'd like to be able to use it for, the things that you think would be important to improve it for wider use and so on.
Please, whether you're a frequent user or an occasional look-at-the-list type, take a moment to let us know your opinions.
What do you use Squeak for?
If you don't use Squeak, why not?
If you used Squeak in the past and don't now, what pulled you away?
What does Squeak lack that you think might make you use it for 'regular' development?
What things are too hard or annoying to do?
What would you like to be able to use Squeak for?
tim
--
tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim
C for sinking, java for drinking, Smalltalk for thinking
I just noticed the list filtering works moderately well for the
directory hierarchy on the left side, but completely unresponsive on
the righthand side for the file list.
Chris Muller uploaded a new version of Morphic to project The Trunk:
http://source.squeak.org/trunk/Morphic-cmm.1462.mcz
==================== Summary ====================
Name: Morphic-cmm.1462
Author: cmm
Time: 3 September 2018, 8:57:57.317349 pm
UUID: 048b437d-9cac-4a1e-a0e9-0e672aca738f
Ancestors: Morphic-kfr.1460
Fix halo-invocation on rotated morphs.
=============== Diff against Morphic-kfr.1460 ===============
Item was changed:
----- Method: PasteUpMorph>>tryInvokeHalo: (in category 'events-processing') -----
tryInvokeHalo: aUserInputEvent
"Invoke halos around the top-most world container at aUserInputEvent's #position. If it was already halo'd, zero-in on its next inward component morph at that position. Holding Shift during the click reverses this traversal order."
| stack innermost haloTarget |
Preferences noviceMode ifTrue: [ ^ self ].
Morph haloForAll ifFalse: [ ^ self ].
"the stack is the top-most morph to bottom-most."
stack := (self morphsAt: aUserInputEvent position unlocked: true) select:
[ : each | each wantsHaloFromClick or: [ each handlesMouseDown: aUserInputEvent ] ].
innermost := aUserInputEvent hand halo
ifNil: [ stack first ]
ifNotNil:
[ : existingHalo | stack allButFirst "existingHalo is first on the stack, not a target"
detect: [ : each | each owner == self ]
ifFound:
[ : worldContainer | "Is existingHalo's target part of the same worldContainer as the morph clicked?"
(existingHalo target withAllOwners includes: worldContainer)
ifTrue: [ "same hierarchy, let #transferHalo: continue to handle it for now." ^ self ]
ifFalse:
[ "different hierarchy, remove + add."
aUserInputEvent hand removeHalo.
aUserInputEvent shiftPressed
ifTrue: [ stack second "first is still the just removed halo" ]
ifFalse: [ worldContainer ] ] ]
ifNone: [ "Shouldn't get here, but defensive code." self ] ].
"If modifier key is pressed, start at innermost (the target), otherwise the outermost (direct child of the world (self))."
+ haloTarget := (innermost == self or: [aUserInputEvent shiftPressed])
- haloTarget := aUserInputEvent shiftPressed
ifTrue: [ innermost ]
+ ifFalse:
+ [ "Find the outermost owner that wants it."
+ innermost withAllOwners reversed allButFirst
+ detect: [ : each | each wantsHaloFromClick ]
+ ifNone: [ "haloTarget has its own mouseDown handler, don't halo." ^ self ] ].
- ifFalse: [ innermost == self ifTrue: [innermost] ifFalse: [(innermost withAllOwners copyWithout: self) last] ].
- haloTarget wantsHaloFromClick ifFalse: [ "haloTarget has its own event handler." ^ self ].
"Now that we have the haloTarget, show the halo."
aUserInputEvent hand
newMouseFocus: haloTarget
event: aUserInputEvent.
haloTarget invokeHaloOrMove: aUserInputEvent.
"aUserInputEvent has been consumed, don't let it cause any further side-effects."
aUserInputEvent ignore!
Hi All,
the latest VMs support a new facility which catches and reports
exceptions during FFI calls as primitive failures. That means that if you
have the relevant support code loaded (described below) and depending on
dialect, you write your FFI interface method to contain an error code, or
you're using the UnifiedFFI which uses invokeWithArguments:, then any
exception that occurs during the FFI call will be caught and reported to
use with the error code bound to an instance of ExceptionInFFICall, which
contains a platform-specific error code and the pc at which it occurred.
To use this facility you'll need to download a VM built yesterday or later
(it should be derived from VMMaker.oscog-eem.2435 or later), or build your
own from the tip of the Cog branch in opensmalltalk/vm. You'll then need
to update the image code to install ExceptionInFFICall appropriately:
in Pharo6 load SLICE 22367
in Squeak load the latest FFI code from source.squeak.org/FFI and update
your image from trunk
in Cuis, you'll need to adapt these changes to Cuis (sorry!!)
There are two command-line flags to override the default behavior.
[-]-failonffiexception causes the handling to be applied to all FFI calls,
so if a method doesn't contain an error, you'll just see a primitive
failure, and if ExceptionInFFICall is not installed you'll see only an
error number in the call's error code.
[-]-nofailonffiexception ignores exceptions during FFI calls, hence
defaulting to the old behavior of crashing the VM (which may be useful if
one is using a low-level debugger to debug the VM and/or external code).
HTH
_,,,^..^,,,_
best, Eliot