Hello,
I have successfully proceeded in running TweakCore on the recent Squeak 4.4
trunk image (from Jenkins).
And one of the famous existed applications developed in Tweak is the OpenGL
procedural textures generator by David Faught.
I make it also loadable to the current Squeak.
You could download the ready to run image from here:
http://krestianstvo.org/TweakCoreOpenGL-squeak44.zip
or
execute in the workspace in own image:
"1. Load FFI"
(Installer repository: 'http://source.squeak.org/FFI'
)
install: 'FFI-Pools';
install: 'FFI-Kernel';
install: 'FFI-Tests'..
"2. Load CroquetGL "
(Installer repository: 'http://www.squeaksource.com/CroquetGL')
install: '3DTransform';
install: 'OpenGL-Pools';
install: 'OpenGL-Core'.
"3. Load TweakCore and Procedural textures application for Tweak"
(Installer repository: 'http://sdk.krestianstvo.org/sdk/inbox')
install: 'tweakcore';
install: 'Tweak-OpenGL-sn.3'.
"4. Set the default settings in Tweak"
CDefaultWidgetLibrary setDefaultSettings.
"5. Run one of two examples"
CProjectMorph open: Wrinkle1.
"or"
CProjectMorph open: Wrinkle2.
The attached screenshot shows the running application.
Regards,
Nikolay
I'm submitting a bug fix and thought I'd ask what the current favoured procedure is. Simply submitting is as irritating as it ever was in Mantis, but once I've done that, uploaded my fix and made a note about it… what do we do next?
To whom might I assign it for action in getting into the image for the next release? Or is that done some other way now? Is there documentation on the current process that I failed to spot?
tim
--
tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: XO: Execute Operator
Want to make $1000.00 (that’s one thousand USD in case I mistyped the number of zeros) and be a hero?
I’m seriously not interested in delving into the insanity of either automake nor cmake; my experiences thus far have left scars. So, in order to avoid pain whilst getting a Cog/stackvm build system that gets reasonably close to that in place for the plain interpreter (see squeakvm.org) - with a side aim of eventually merging - I am offering some money.
For someone that actually knows this stuff I suspect it is an easy, if perhaps long-winded, job. The acceptance test that determines when payment can be made would be
a) Eliot & Ian agreeing that it is good enough to replace the auto-blargh horror that is currently in use (that’s a pretty high bar)
and
b) successful addition of the Raspberry Pi faster-blt code to the cog/stack build, as with the current plain interpreter build
tim
--
tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim
Useful Latin Phrases:- Canis meus id comedit = My dog ate it.
(Installer monticello mc: (MCHttpRepository new location:
'http://source.squeak.org/FFI'))
install: 'FFI-Kernel-eem.24.mcz'. "There's a -tbn.25, but that's
not important to this post"
fails with an MNU: ExternalFunction class >> callingConventionFor:.
As far as I can see what's happening is this:
* during the loading of the mcz ExternalFunction is defined,
* a method is parsed (#XOpenDisplay, which has a pragma <cdecl:
X11Display* ''XOpenDisplay'' (char*) module:''X11''>)
* Parser >> externalFunctionDeclaration checks whether
ExternalFunction is defined.
* It is, so tries to evaluate `descriptorClass callingConvention:
here` and boom, because ExternalFunction class >>
callingConventionFor: _has not been loaded yet_.
I've seen this kind of issue with Helvetia code: sometimes you simply
have to load class-side methods first.
Thoughts? Lukas worked around the issue with his Helvetia code by
directly patching Monticello, and ripping out its "try to do atomic
loading" mechanism.
frank
On 10/26/13, Bob Arning <arning315(a)comcast.net> wrote:
> http://69.251.218.6:9116/ can give you a pretty good picture of the
> evolution in this area.
>
> Cheers,
> Bob
Bob
does it contain _all_ the change sets from 1998 - 2008? It seems that
in 2008 the update mechanism was changed to Monticello files, right?
Did you think it would be possible of running an from 0001 to 7179,
so to say "replaying the evolution"?
It would be nice to have a graphical display of which areas have been
touched and which ones not. Possibly in the form of a movie.... (e.g.
a rectangle representing a class category sized according to code size
with colors indicating changes, animated gif?)
--Hannes
0001tk_test.doit
"Just a test if the update broadcasting is working"
Transcript show: ' You got an external update'; cr.
0002tk_collapse_RF.cs
'From Squeak 1.31 of Feb 4, 1998 on 8 May 1998 at 4:31:32 pm'
.........
7179AdvanceTo3dot10dot2.cs
>From Squeak3.10.2beta of 5 June 2008 [latest update: #7175] on 5 June
2008 at 2:53:19 pm'
I have created a repository for maintaining the trunk 4.5 branch:
MCHttpRepository
location: 'http://ss3.gemstone.com/ss/FreeTypePlus'
user: ''
password: ''
FreeType requires a plugin.
It is pre-compiled and distributed with Pharo VM, so it's the easiest way
to test it...
On 31 October 2013 22:19, <commits(a)source.squeak.org> wrote:
> Frank Shearar uploaded a new version of ToolBuilder-Kernel to project The Trunk:
> http://source.squeak.org/trunk/ToolBuilder-Kernel-fbs.58.mcz
>
> ==================== Summary ====================
>
> Name: ToolBuilder-Kernel-fbs.58
> Author: fbs
> Time: 31 October 2013, 10:18:57.495 pm
> UUID: f4158a78-a770-0548-a26b-a9cfd0ea9beb
> Ancestors: ToolBuilder-Kernel-dtl.57
>
> Step 1 of moving control over display depth to the UIManagers.
>
> =============== Diff against ToolBuilder-Kernel-dtl.57 ===============
So I think the next step is to make the DisplayScreen methods forward
entirely to UIManagers. But getting this wrong means bad things. So I
thought I'd check first that this will work out:
* make the change
* commit Graphics
* change the update configuration map to load the UIManagers before Graphics.
* copy Graphics to trunk
Think it'll work?
frank