Re: [Pharo-users] Namespaces (was Re: Behold Pharo: The Modern Smalltalk)

[Ronie Salgado]

I do not like the idea of using a dot in class names because dot is already
used to separate expressions in a sequence. I am pretty sure that using dot
may introduce several ambiguities in the parsing process. For example, the
following with the current parser will produce the same AST:

someMethod
>   Chronology.Date
>

vs

someMethod
>   Chronology.
>   Date
>

Using spaces for supporting namespace in theory allows for an
implementation that does not require to make several modifications to the
compiler (except for efficiency reasons). Using some other separator such
as two colons ( :: ) may also solve this parsing ambiguity problem. A
single colon ( : ) also posses this ambiguity problem because it could
clash with keyword message sends.

P.S: A bigger problem that I remember from that ESUG discussion is having
namespaced/modularized selectors and extension methods. :)

Best regards,
Ronie


El dom., 22 dic. 2019 a las 21:20, Esteban Maringolo ()
escribió:

> There are two uses for namespacing:
> 1. Avoiding class name collisions between different packages
> 2. Modularization
>
> I don't have the use cases for 2, but Torsten had an idea to support
> the dot in the class name, that'd solve the problem 1. (e.g.
> Chronology.Date and YourPackage.Date).
>
> Esteban A. Maringolo
>
> On Sun, Dec 22, 2019 at 8:57 AM ponyatov  wrote:
> >
> > What is the modern state of namespaces support? Maybe in Pharo 8 (or 9)
> >
> > I'm going to model some generic async Smalltalk in Pharo, package-bounded
> > namespaces can save me from prefixing every class name.
> >
> >
> >
> > --
> > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
> >
>
>

Re: [Pharo-users] [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)

[Ronie Salgado]

That looks very cool

For the text editor are you using GtkSourceView or something else?

Greetings,
Ronie

El jue., 18 abr. 2019 a las 7:23, Esteban Lorenzano ()
escribió:

>
>
> On 18 Apr 2019, at 13:08, PBKResearch  wrote:
>
> +1 to Norbert. In particular, does it mean that, from Pharo 8, we will be
> *required* to install Gtk3 backend to use Pharo?
>
>
> For now is in early development so there is no easy way to install (since
> there are things to replace/fix in current image).
> We will provide an install script soon (or maybe a prepared image, while
> we arrive to have a reliable baseline).
>
> And no, you will not need it. Gtk3 bindings are an extra. If you want to
> do a desktop application (for example Schmidt is doing it), maybe you will
> want to install it. Otherwise you will continue as before.
>
> And to be clear: Pharo 8 WILL NOT be a Gtk3 application.
> Even if eventually the IDE will be able to run with it (since it will be a
> Spec 2.0 based IDE), there are a lot of huge things that need to be
> migrated before (and the GTInspector is not big: Calypso is).
> And still then (maybe in Pharo 9), running with Gtk3 will be a choice.
>
> Esteban
>
>
> Peter Kenny
>
> *From:* Pharo-users  *On Behalf Of 
> *Norbert
> Hartl
> *Sent:* 18 April 2019 11:58
> *To:* Pharo users users 
> *Cc:* Pharo Dev 
> *Subject:* Re: [Pharo-users] [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3
> bindings)
>
> Great!
>
> Can you explain what is there, what somebody can load and what to expect.
> And even more important: what not to expect?
>
> I don’t get any of the essential details from this mail.
>
> Norbert
>
>
>
>
> Am 18.04.2019 um 12:08 schrieb Esteban Lorenzano :
>
> People that assisted to Pharo Days 2019 (or that follow my twitter
> account) already know this, but it needs to be formally announced:
>
>
> *We are working on Spec 2.0, and it will provide not just the classic
> Morphic bindings but also a new option for developers: Gtk3 bindings!*
>
> Why we want a Spec 2.0 with different backends?
>
> There are reasons that converged to decide us to make it:
>
>
>- First, to provide a validated abstract Spec 2.0 that can be used
>with different backends, preparing Pharo to be able to switch backends
>without needing to recreate the full IDE from scratch each time (a problem
>we have partially now in our way to deprecate Morphic).
>- Second, because we receive from different sources the requirement of
>having the possibility of developing real native-looking desktop
>applications. Yes, in moment where people talk about the cloud, SaaS and
>web-applications as the "next big thing" (something that is been declared
>since years, by the way), we believe is important to provide this, for two
>big reasons:
>
>
>1. Because there is still an important place for desktop applications
>   market and most medium-size to big business still require them.
>   2. Because Pharo itself is a desktop application! (And we need to
>   provide the best experience possible on it).
>
>
> For us, this is a fundamental step to continue improving Pharo itself, and
> it matches also the work we are doing on going real-headless:  Pharo users
> will be able to start the Morphic world, a Gtk application or the next
> backend to come.
>
> Why Gtk3?
>
> There are some other important players in the "native widgets scene", so
> why we choose Gtk3?
>
> Again, several reasons  were taken into account:
>
>
>- Gtk3 is cross platform. Yes, technically is just "native" in linux,
>but it works on Windows and macOS too.
>- It is very mature and popular.
>- It is made in plain C.
>
>
> Next step: tool migration
>
> The only way to know if you have covered what is needed is actually taking
> real-life use cases and implementing them. We have a list of tools that
> needs to be migrated and we are starting from them:
>
>
>1. Old GT tools will be replaced by new Spec tools (while preserving
>its power).
>2. Calypso UI needs to be rewritten in Spec 2.0 (it is in plain
>Morphic now).
>3. Pharo launcher as a standalone application is a good example of
>what you can do with the Gtk3 bindings.
>
>
> And that's it. Pharo 8.0 will come with Spec 2.0 and users will be able to
> benefit of it immediately :)
>
>
> A small screenshot of the new Inspector (WIP):
>
> 
>
> Esteban
>
>
>

[Pharo-users] [ANN] Git Thermite integration with Iceberg

[Ronie Salgado]

Hello,

Some time ago I presented Git Thermite in this mailing. Git Thermite is a
tool for visualizing Git commits that I am making for my master thesis. Now
I have managed to integrate Git Thermite with Iceberg.

GitHub page: https://github.com/ronsaldo/pharo-git-thermite
Demo video: https://www.youtube.com/watch?v=TdBHpdyFgZE
Visualization learning material:
https://github.com/ronsaldo/pharo-git-thermite/blob/master/doc/learning-material.pdf
Feedback:
https://docs.google.com/forms/d/e/1FAIpQLSeir6VlE3bR78oRsNAp9eHLkUn2Q016wEliOJN7tFlTmYFi8w/viewform

Pharo 7 installation doIt:

Metacello new
   baseline: 'Thermite';
   repository: 'github://ronsaldo/pharo-git-thermite/src';
   load

Please, I would love to get some usage feedback through the Google form :-)

Best regards,
Ronie

Re: [Pharo-users] OpenGL minimum working example?

[Ronie Salgado]

Hi Hernan,

I just added two new examples, UFFIOpenGLOffscreenSamples >> #triangle and
UFFIOpenGLOffscreenSamples >> #quad (using your vertices). I tested it on
Linux and on OS X.

triangle
"
self new triangle
"
| context gl fb colorProgram vertexBuffer |
context := UFFIOpenGLContext new.
colorProgram := self colorProgramFor: context.
vertexBuffer := self immutableVertexBufferFor: context
withPackedFloats: {
"   x  y z r g b a "
{ -0.5 . 0.5 . 0.0 . 1.0 . 0.0 . 0.0 . 1.0 }.
{  0.5 . 0.5 . 0.0 . 0.0 . 1.0 . 0.0 . 1.0 }.
{  0.0 . -0.5 . 0.0 . 0.0 . 0.0 . 1.0 . 1.0 }.
}.

gl := context gl.
fb := context offscreenBufferExtent: 640@480.

context asCurrentDo: [
fb activate.
gl
viewport_x: 0 y: 0 width: 640 height: 480;

clearColor_red: 0.0 green: 0.0 blue: 0.0 alpha: 1.0;
clear: GL_COLOR_BUFFER_BIT;

useProgram: colorProgram validHandle;

bindBuffer_target: GL_ARRAY_BUFFER buffer: vertexBuffer
validHandle.
self activateDefaultVertexLayoutOn: context.

gl drawArrays_mode: GL_TRIANGLES first: 0 count: 3
].

fb asForm asMorph openInWindow.

Best regards,
Ronie

El mar., 13 nov. 2018 a las 1:23, Ben Coman ()
escribió:

>
>
> On Tue, 13 Nov 2018 at 03:37, Hernán Morales Durand <
> hernan.mora...@gmail.com> wrote:
>
>> Hi.
>>
>> I tried to get an OpenGL MWE from
>> https://github.com/ronsaldo/uffi-opengl in both Windows 8.1 and MacOS
>> without luck. What I tried so far is to render a simple figure in a
>> new window, adding this method to UFFIOpenGLOffscreenSamples:
>>
>
> You may also be interested in "Use Metal instead of OpenGL for the main VM
> Window in OS X" ...
> https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/306
>
> cheers -ben
>

[Pharo-users] [ANN] Pharo Git Thermite Release

[Ronie Salgado]

Hello,

I am finally releasing an initial public version of Pharo Git Thermite, a
tool that I am developing as part of my master thesis for visualizing
Monticello and Git commits, for Pharo and Python:

GitHub Page with sources/documentation/issue tracker:
https://github.com/ronsaldo/pharo-git-thermite

Short video examples:
- Monticello Visualization; https://youtu.be/02CUHBmm-K8
- GitHub pull request: https://youtu.be/f196btLfYxM
- Local git commit: https://youtu.be/LCHTiJ4nx3g

Feedback form:
https://docs.google.com/forms/d/e/1FAIpQLSeir6VlE3bR78oRsNAp9eHLkUn2Q016wEliOJN7tFlTmYFi8w/viewform?usp=sf_link

Best regards,
Ronie

Re: [Pharo-users] What next for Pharo vm?

[Ronie Salgado]

>
>
> I was thinking the vm is able to run more than one bytecode set. Why
> couldn’t our vm support both Pharo and Java bytecodes?

Perhaps a simpler way is to make a translator from Java bytecodes -> Pharo
(Sista) bytecodes. I believe that ikvm did something similar for .NET. The
hardest part of this would actually be on parsing the .class files.

Best regards,
Ronie

2018-04-22 21:31 GMT-03:00 Esteban A. Maringolo :

> On 22/04/2018 11:03, henry wrote:
> > I was thinking the vm is able to run more than one bytecode set. Why
> > couldn’t our vm support both Pharo and Java bytecodes?
>
> Smaltallk/X provides that Smalltalk/Java code duality.
>
> But I think if Pharo ever pursues that path the best thing would be to
> make it run in a VM such as Truffle/GraalVM [1]. A longest path maybe,
> but you'll be able to piggyback on an existing community of VM
> developers, and be able to interact not only with Java but it other
> languages as well.
>
> [1] https://www.graalvm.org/
>
> Regards!
>
> --
> Esteban A. Maringolo
>
>

Re: [Pharo-users] Any perspective of Woden in Pharo 6.1/7 ?????

[Ronie Salgado]

>
> Do you have a travis or jenkins for woden in Pharo 7?

This is on my big todo list. In fact I need the travis to be able to
support Windows. During the last months I have been rewriting the core of
Woden 2 in order to improve stability and reduce dependencies. By using
Lowtalk for the math library, I removed the requirement on Lowcode.

During the weekend I am gonna spend some time on implementing the scripts
for Travis.

Best regards,
Ronie

2018-01-12 13:47 GMT-03:00 casimiro barreto :

> Will try. Currently on 2 projects involving pharo. The most pressing one
> is a system for the calculation of uncertainties in measures. This system
> is part of a homologation system for smart card readers and smart card
> chips. The other is a simulation system that´s under non disclosure clause.
> Woden would be used in a third incoming project (simulations in crowd
> management in airports).
>
> Best regards,
>
> Casimiro
>
> 2018-01-10 19:43 GMT-02:00 Alexandre Bergel :
>
>> Hi Casimiro!
>>
>> Sorry for the late reply.
>> We do have a working version of Woden for Pharo 7.
>> It would be great if you could try.
>> https://github.com/ronsaldo/woden2
>>
>> On OSX, I did:
>> -=-=-=-=-=-=-=-=-=
>> git clone https://github.com/ronsaldo/woden2.git
>> cd woden2
>> ./loadWoden2.sh
>> -=-=-=-=-=-=-=-=-=
>>
>> It takes time to install & compile (~ 10 minutes?), but it works well
>>
>> Alexandre
>>
>>
>> > On Jan 2, 2018, at 5:21 AM, Casimiro - GMAIL <
>> casimiro.barr...@gmail.com> wrote:
>> >
>> > Is there any perspective of Woden working in Pharo 6.1 or later
>> versions (7)
>> >
>> > Best regards,
>> >
>> >
>> > Casimiro
>> > --
>> > The information contained in this message is confidential and intended
>> to the recipients specified in the headers. If you received this message by
>> error, notify the sender immediately. The unauthorized use, disclosure,
>> copy or alteration of this message are strictly forbidden and subjected to
>> civil and criminal sanctions.
>> >
>> > ==
>> >
>> > This email may be signed using PGP key ID: 0x4134A417
>>
>>
>
>
> --
> The information contained in this message is confidential and
> intended to the recipients specified in the headers. If you received
> this message by error, notify the sender immediately. The
> unauthorized use, disclosure, copy or alteration of this message
> are strictly forbidden and subjected to civil and criminal sanctions.
>

Re: [Pharo-users] Smalltalkers will, eventually, win. So says this old C++ programmer.

[Ronie Salgado]

Hi kilon,

Some weeks ago I tried the C live programming technique for the Ludum Dare.
It works very well. For that occasion I wrote this short article
https://ldjam.com/events/ludum-dare/38/smalcoded-a-small-eco-destroyed-world/a-diabolical-game-for-a-diabolical-experiment
. The game ended pretty well in my opinion:
https://ldjam.com/events/ludum-dare/38/smalcoded-a-small-eco-destroyed-world
.

Why C++ coders still endure long compile times when they could test code in
> an instant through live coding ? Well in games C++ live coding is actually
> very popular, so some are already aware of the huge advantages of live
> coding.
>
I work for a video game company that is using Unreal Engine 4, we do not
use the C++ live coding features. I do not like the way that they
implemented live coding, and the bindings for their Blueprint visual
language. We all hate the long compilation times of UE4, the fact that they
use their own undocumented makefile system which is using a bunch C# files
for building their project. We also do not like the fact that from time to
time, we see that we are missing some #includes because of the unity builds
that are done by the unreal build system (merging several .cpp before
compiling them).


> Another shock for me is how simple it is to implement an image file format
> for other languages. The shock was that the OS already uses image files
> like pharo image that calls them "memory mapped files" they are used for
> sharing memory which in turn is what is used for DLLs. The advantage over
> the pharo image is that it crash prone, because it is handled by the OS and
> not the language or the VM. Which means that even if your app crashes the
> image is still saved and you lose no live data which is not the case with
> pharo image. The disadvantage is that of course they are not OOP friendly
> as the pharo image is and they are not language specific as pharo image is.
>
The biggest problem of these other language language is the lack of
reflection information at runtime. The second other problem, is the lack of
#become:, for swapping objects when their data layout changes.

Elf files, PE files (.exe, .dll) and other executable formats are process
images with a symbol table and relocation metadata.

If the operating system allowed to modify in an easy way the symbol table
of the current loaded process, it could be even cooler. In Linux, dlopen is
implemented in terms of open() and mmap().

Best regards,
Ronie


2017-05-10 16:48 GMT-03:00 p...@highoctane.be :

> Or BeanShell
>
> http://www.beanshell.org/
>
> or Groovy
> https://zeroturnaround.com/rebellabs/scripting-your-java-
> application-with-groovy/
>
> or Spring-Shell
> https://projects.spring.io/spring-shell/
>
> Example app I am using (and extending) for Hadoop work:
> https://github.com/sequenceiq/ambari-shell
>
> When one looks inside a command, this is something easily achievable with
> pragmas.
>
> https://github.com/sequenceiq/ambari-shell/blob/master/src/
> main/java/com/sequenceiq/ambari/shell/commands/BasicCommands.java
>
> There is nothing extraordinary in these pieces of tech ("pas de quoi
> casser trois pattes à un canard" in French).
>
> But we need our own house in order on the CLI. GSoC time!
>
> Phil
>
>
>
>
> On Wed, May 10, 2017 at 7:38 PM, blake watson 
> wrote:
>
>> There is a Java REPL. You could Google that.
>>
>> There's also a some kind of commercial hot/live compiler tool called
>> "JRebel". Haven't tried it (don't code Java).
>>
>> On Wed, May 10, 2017 at 4:29 AM, askoh  wrote:
>>
>>> Kilon:
>>>
>>> This is revelation to me. I am enduring 10 minute turnaround for every
>>> edit I make in *.java, xml, jsp, js files. 4 minute compile and 6 minute
>>> web server update. How can I get that shortened to 10 seconds say? What
>>> links can help? What search terms to google?
>>>
>>> Thanks,
>>> Aik-Siong Koh
>>>
>>> On May 10, 2017, at 3:20 AM, kilon.alios [via Smalltalk] <[hidden email]
>>> > wrote:
>>>
>>> Just to remind people here that all languages with long compile times
>>> can be avoided live coding style through the use of dynamically linked
>>> libraries known as DLLs on windows, shared libraries on linux (*.so) and
>>> macos (*.dylib) . Also Swift in particular comes with a live coding
>>> environment called "Playgrounds" which is also very flexible.
>>>
>>> Haskell do not know if they have something similar to Playgrounds but I
>>> will be surprise if they do not have something at least inferior. All
>>> languages support DLLs including ours.
>>>
>>> Live coding is actually super easy to implement and believe me I was
>>> sceptical about it at first and if I had read this post I am making now I
>>> would call me crazy. But after implementing live coding in python, C and
>>> C++ , now I am a believer. Of course the real question here is if its that
>>> easy why people do not use it . From what 

Re: [Pharo-users] Editor with syntax highlighting awareness

[Ronie Salgado]

Hi All,

Here is a basic example for doing a very simple syntax highlighted text
editor:

=
styler := MyTextStyler new.

browser := GLMTabulator new.
browser row: #row.

browser transmit to: #row; andShow: [ :composite |
composite custom: (GLMRubricHighlightedTextPresentation new
editingMode: [GLMHighlighterTextRubEditingMode
withStylerDecorator: (GLMHighlighterTextStylerDecorator new
styler: styler)]) ].

browser openOn: 'Some text with highlighting $@'.
=

Best regards,
Ronie

2017-05-08 11:42 GMT-03:00 Offray Vladimir Luna Cárdenas <
offray.l...@mutabit.com>:

> Hi,
>
> I would like something along the lines of the recent code syntax thread.
> Maybe something like:
>
> ===
>
> TextModel new
> isForCode: 'markdown';
> text: (Collection>>#anyOne) sourceCode;
> aboutToStyle: true;
> openWithSpec
>
> ===
>
> This would do a great adding for Grafoscopio.
>
> Cheers,
>
> Offray
>
>
> On 07/05/17 11:57, p...@highoctane.be wrote:
>
>> I want to do such an editor.
>>
>> Preferrably something fast.
>> And in the current Pharo.
>>
>> There have been several text models, Rubric etc.
>>
>> What is the quickest way to get such a thing?
>>
>> Features:
>>
>> Load/Save content
>> Highlight keywords based on syntax parsing
>> Act on the element under the cursor
>> Act on the element when (modifier)clicking on it (or hovering).
>> Fast (or at least, not sluggish on a "normal" (ie Core i5 1.8Ghz) laptop)
>>
>> This is really something I miss being able to do in Pharo.
>>
>> Lots of code is using "STHStyler" things but there seems to be no easy
>> way to extend that (as it seems to be using the AST or something like
>> that).
>>
>> I am okay with a first easy approach to highlighting, like in Vim
>> where one puts a syntax file with not that many things.
>>
>> Phil
>>
>>
>>
>
>


MyTextStyler.st
Description: Binary data

Re: [Pharo-users] Fwd: GSoC 2017: Pharo Consortium has been accepted as a mentor organization!

[Ronie Salgado]

Congratulations!

2017-02-27 16:54 GMT-03:00 Stephane Ducasse :

> Super good news.
> I need good news in this moment!
>
> On Mon, Feb 27, 2017 at 8:42 PM, Serge Stinckwich <
> serge.stinckw...@gmail.com> wrote:
>
>> On Mon, Feb 27, 2017 at 8:19 PM, Peter Uhnak  wrote:
>> >
>> > Congratulations!
>> >
>> > p.s. I think my name was there from last year (I didn't have time for
>> this this year), so if you encounter it anywhere, feel free to remove it.
>>
>> BTW, I add you name, because you help a lot last year :-)
>>
>> --
>> Serge Stinckwich
>> UCBN & UMI UMMISCO 209 (IRD/UPMC)
>> Every DSL ends up being Smalltalk
>> http://www.doesnotunderstand.org/
>>
>>
>

Re: [Pharo-users] Crash in Athens

[Ronie Salgado]

Hello,

http://forum.world.st/Too-frequent-crashes-td4927143i20.html#a4934027

Try changing AthensCairoSurface >> asForm into the following method:

asForm

"create a form and copy an image data there"
| form |
self checkSession.

self flush.
form := Form extent: (self width@self height) depth: 32.
form unhibernate.
LibC memCopy: self getDataPtr to: form bits size: self width*self
height*4.
^ form

This seems to improve the stability a lot. I have already told Esteban to
take a better look.

Best regards,
Ronie

2017-02-22 13:47 GMT-03:00 Alexandre Bergel :

> Dear Alexander,
>
> Sine the new FFI of Pharo, using Athens has become unreliable. This is a
> pity, but fixing this is not trivial at all (we have been trying for years).
>
> What exactly are you doing with Athens?
>
> Alexandre
>
>
> > On Feb 22, 2017, at 12:55 AM, Alexander Samoylovich <
> samoylov...@gmail.com> wrote:
> >
> > Hello
> >
> > I am writing graphic demo programs using Athens on Mac Sierra.
> > Time by time Pharo VM crashes. Programs not using Athens work reliably.
> > I believe the behavior is reproducible.
> > How should I report a bug?
> >
> > Alex
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>

Re: [Pharo-users] Using a Unix filedescriptor in a FileStream?

[Ronie Salgado]

Hi Holger,

Sorry for not noticing this thread before. Some months ago, I did some
experiments myself using inotify and epoll, with the UFFI. I was creating a
file system monitoring API similar in design to OSWindow. I just did some
minor changes for making this usable along with making a configure script.
I left all of the code and some scripts for loading the FileSystemMonitor
API at: http://smalltalkhub.com/#!/~ronsaldo/OSCalls .

For testing the monitoring API, try the following in a playground:

monitor := FileSystemMonitor for: '.' do: [ :event |
Transcript show: event; cr.
].

If you do this, open a Transcript and you start browsing some methods in
Nautilus, you will start receiving some events where Pharo is accessing the
.changes file. For the destroying the monitor and stop receiving the
events, you can do the following:

monitor destroy.

Currently the events given by this API are only holding a copy of the raw
inotify event in rawEvent and a copy of the raw path in rawPath. Further
work is required for translating the events into a more platform
independent interface, and for supporting OS X and Windows with this API.
However, this is already something that could be useful to you.

Best regards,
Ronie

2016-09-20 15:26 GMT-03:00 Holger Freyther :

> Hi,
>
> I explored to use the Linux inotify API using UFFI. The
> inotify_init/inotify_init1 routine will me a Unix filedescriptor and I
> would like to
>
> a.) monitor it for being readable
> b.) read from it with a stream
>
>
> For a.) I have found the AioEventHandler and think I will be able to call
> >>#descriptor: directly and then can use it (still figuring out the API,
> probably just wait for the >>#changed: call).
>
> For b.) I thought I could use AttachableFileStream but that required a
> "fileId" but not a filedescriptor. Is there a way I can read from my fd
> using the standard stream API (otherwise I can try to use UFFI for read)
>
>
> regards
> holger
>

Re: [Pharo-users] OpenGLES2 binding available!

[Ronie Salgado]

>
> Isn't it what Ronie is working on?

I am not working with OpenGL or OpenGL ES anymore. I am moving all of my
efforts into Woden 2, the AbstractGPU (an abstraction layer for
Vulkan, Direct3D 12 and Metal), and Dastrel (Data Stream Language) a custom
shader language whose compiler I implemented in Pharo, with a backend for
SpirV, GLSL and C++. I still have to implement the backends for Metal and
HLSL.

Thibault is interested more on being able to use OpenGL ES 2.0 directly in
the playground, for teaching purposes without any abstraction layer
underlying. I do not agree with many of his approaches, too low level, and
many of themp do not work well with Pharo VM. One of the biggest issue of
OpenGL is related with vsync, which is an operation that can block all of
the Pharo processes, until we get a VM with the threaded FFI, which will
have in the near future. It will use the UnifiedFFI API, so we will not
have to further changes to take advantage of the threaded ffi in the user
code.

A far worse problem with OpenGL is that the current OpenGL context is a
thread local variable, which do not interact at all with Pharo processes.
This is the reason of why I added the OSWindowRenderThread class for
serializing OSWindow and OpenGL animations. SDL2 renderers are usually
implemented using OpenGL. They are two correct solution for this problem:
- Having a VM that maps each Pharo Process into an operating system thread,
- Not using OpenGL at all.

The others low level graphics API (Vulkan, Direct 3D and Metal) do not rely
on a global thread local storage variable. These APIs are object oriented,
so handles are passed in each API call.

Currently, I have an Athens backend above Woden 2, which is only supporting
Vulkan for now. Since this backend is for Woden 2, it has some dependencies
in the Woden 2 Math and the Lowcode NativeStructure. This means that the
Woden 2 Athens backend has a strong dependency in the the modified
OpalCompiler that uses the Lowcode extended byte code set, and the the
modified PharoVM that implements these extra bytecode in the just in time
compiler.

Anyway, implementing a Athens backend from scratch is a really hard
problem, because paths can be concave, curve and self intersecting. Drawing
a path, unlike drawing a triangle is a global operation, for which GPUs
were not designed for. The easiest and most robust technique for drawing a
path using the GPU is to flatten the path using De Casteljau's algorithm
and then using the stencil buffer technique for drawing concave polygons
that was described in the OpenGL red book (
http://www.glprogramming.com/red/chapter14.html#name13 ). The problem of
this technique is that involves many state changes(glStencil*)  and drawing
commands(glDrawElements) per path, which are the most expensive operations
when using OpenGL. The alternative is to perform a triangulation in the CPU
of paths, or to use one of the newer low level APIs such as Vulkan and
Direct 3D 12 which were designed to reduce or eliminate the cost of state
changes and drawing commands.

Path stroking is an even harder problem, which I have not solved yet. The
standard approach is to convert a stroked path into a path that can be
filled. The problem is that bezier offset curves are not bezier curves, so
they have to be approximated. Fortunately, since this operation is backend
agnostic, it can be used and reused by many Athens backends. Since stroking
is not critical for my needs, I do not think I will implement it soon
properly. Currently I am just drawing a 1 pixel thick line, which can look
horrible, but is better than nothing. One algorithm that seems to be simple
to implement is one described in a paper from the Cairo people, which uses
the Minkowksi  Sum between the outline of the path to be stroked, and shape
of the pen that is stroking
the path: http://keithp.com/~keithp/talks/cairo2003.pdf

Soon I will merge the Lowcode instructions into the SqueakVM/Cog VM to
integrate these bytecodes into the mainline VM.

I will not publish Woden 2 until the dependencies and Woden 2 itself can be
loaded easily.  Soon I will publish properly the Dastrel shader language
and the Slovim backend. Slovim name comes from Smalltalk Low levelish
VIrtual Machine, an intermediate representation heavily modeled after the
one used in LLVM, implemented in Pharo, some very basic optimizations(basic
constant folding, inlining and some dead code generation), and a code
generator backend for SpirV, GLSL and C++. My biggest issue before
publishing this compiler are:
- Implementing a command line interface.
- Doing an easy to install and use package for Linux, OS X and Windows.
- Documenting the language and the compiler.

Best regards,
Ronie

2016-07-28 19:31 GMT+02:00 Alexandre Bergel :

> I would love to see an athens back-end for it.
>
> Isn't it what Ronie is working on?
>
> Alexandre
>
>
> Le 19/7/16 à 13:19, Thibault Raffaillac a écrit :
>
> Hi all,
>
> My tiny binding for 

Re: [Pharo-users] [UFFI] Using a nested structure

[Ronie Salgado]

I compiled the DLL using Visual Studio 2015 Community Edition. Later I will
check with mingw.

2016-07-05 14:58 GMT+02:00 Merwan Ouddane <merwanoudd...@gmail.com>:

> Using codeblocks, mine are:
>
> mingw32-g++.exe -m32 -DBUILD_DLL -c main.cpp -o obj\Release\main.o
> mingw32-g++.exe -shared -Wl,--output-def=bin\Release\libTest.def
> -Wl,--out-implib=bin\Release\libTest.a -Wl,--dll  obj\Release\main.o  -o
> bin\Release\Test.dll -s -m32
>
>
> On Tue, Jul 5, 2016 at 2:52 PM, Merwan Ouddane <merwanoudd...@gmail.com>
> wrote:
>
>> I am not moving from another plateform :/
>>
>> I tried it in pharo 6 and I it didn't work either.
>>
>> It could be my dll. What is your compilation line for the dll ?
>>
>> Thanks you,
>> Merwan
>>
>> On Tue, Jul 5, 2016 at 2:14 PM, Ronie Salgado <ronies...@gmail.com>
>> wrote:
>>
>>> Hi Merwan,
>>>
>>> I tested this on Pharo 6 and it is working in Windows. However, in 32
>>> bits Window doubles have an 8 byte alignment, unlike Linux where they have
>>> a 4 byte alignment.
>>>
>>> Can you try doing the following before performing the ffi call in
>>> Windows, if you are moving an image from Linux or OS X:
>>>
>>> Vec3 rebuildFieldAccessors.
>>> Position rebuildFieldAccessors.
>>>
>>> Best regards,
>>> Ronie
>>>
>>> 2016-07-05 11:11 GMT+02:00 Merwan Ouddane <merwanoudd...@gmail.com>:
>>>
>>>> Hi,
>>>>
>>>> I have an issue whith nested structures.
>>>>
>>>> I made some "dummy" structures in c:
>>>>
>>>>
>>>> typedef struct vec3 {
>>>>  double data[3];
>>>> } vec3;
>>>>
>>>> typedef struct position {
>>>>  int i;
>>>>  vec3 vec;
>>>> } position;
>>>> And a "dummy" function to fill it:
>>>> void fillStruct(position *position)
>>>> {
>>>> position -> i = 19;
>>>> (position -> vec).data[0] = 1;
>>>> (position -> vec).data[1] = 2;
>>>> (position -> vec).data[2] = 3;
>>>> }
>>>>
>>>> But I can't make the nested structure work.
>>>> The "i" is correctly set to 19 but I have values that doesn't make any
>>>> sense in the vec3 structure.
>>>>
>>>> In Pharo
>>>> I declared the Double3 type for the array inside Vec3:
>>>> Double3 := FFITypeArray ofType: 'double' size: 3
>>>>
>>>> Vec3>>fieldsDesc
>>>> ^ #(
>>>> Double3 v;
>>>> )
>>>>
>>>> And the position:
>>>> Position>>fieldsDesc
>>>> ^ #(
>>>> int i;
>>>> Vec3 vec;
>>>> )
>>>>
>>>> The ffi call:
>>>> ^ self ffiCall: #(void fillStruct(Position *position)) module:
>>>> 'Test.dll'
>>>>
>>>> Sorry for the long / messy mail :p
>>>>
>>>> Any clues ?
>>>>
>>>> Cheers,
>>>> Merwan
>>>>
>>>
>>>
>>
>

Re: [Pharo-users] [UFFI] Using a nested structure

[Ronie Salgado]

Hi Merwan,

I tested this on Pharo 6 and it is working in Windows. However, in 32 bits
Window doubles have an 8 byte alignment, unlike Linux where they have a 4
byte alignment.

Can you try doing the following before performing the ffi call in Windows,
if you are moving an image from Linux or OS X:

Vec3 rebuildFieldAccessors.
Position rebuildFieldAccessors.

Best regards,
Ronie

2016-07-05 11:11 GMT+02:00 Merwan Ouddane :

> Hi,
>
> I have an issue whith nested structures.
>
> I made some "dummy" structures in c:
>
>
> typedef struct vec3 {
>  double data[3];
> } vec3;
>
> typedef struct position {
>  int i;
>  vec3 vec;
> } position;
> And a "dummy" function to fill it:
> void fillStruct(position *position)
> {
> position -> i = 19;
> (position -> vec).data[0] = 1;
> (position -> vec).data[1] = 2;
> (position -> vec).data[2] = 3;
> }
>
> But I can't make the nested structure work.
> The "i" is correctly set to 19 but I have values that doesn't make any
> sense in the vec3 structure.
>
> In Pharo
> I declared the Double3 type for the array inside Vec3:
> Double3 := FFITypeArray ofType: 'double' size: 3
>
> Vec3>>fieldsDesc
> ^ #(
> Double3 v;
> )
>
> And the position:
> Position>>fieldsDesc
> ^ #(
> int i;
> Vec3 vec;
> )
>
> The ffi call:
> ^ self ffiCall: #(void fillStruct(Position *position)) module: 'Test.dll'
>
> Sorry for the long / messy mail :p
>
> Any clues ?
>
> Cheers,
> Merwan
>

Re: [Pharo-users] New project: AR.Drone communication API in Pharo

[Ronie Salgado]

Ok, I made a cleanup on the OSWindow joystick support. I also added the
OSWindowGenericRenderer interface which is implemented by a thin wrapper
around the SDL2 renderer interface. I have tested this on Linux using a
XBox 360 controller (using SDL2 GameController interface) and a PS2
controller via an USB adapter (using SDL2 Joystick interface). Later I will
test it on Windows and Mac.

=
Here is the demo:
https://www.youtube.com/watch?v=lABfEmToHLQ=youtu.be

OSWindowJoystickExample new open.

Xbox 360/mapped controls
Left stick: move character
X button: shoot
Start: reset

=

I also added a simple examples using the OSWindowGenericRenderer:

OSWindowGenericRendererDrawingExample new open.

=

I also modified the OSSDL2Driver >> #isSuitable method to not call the
hasPlugin method. The plugin seems to be unnecessary according to several
posts, and I am too lazy for fixing it. I guess that this should be
eventually integrated into Pharo 5 after some reviewing. Before that, the
latest version of OSWindow should be loaded manually. For that, the
packages should be loaded in the following order:

OSWindow-Core
OSWindow-SDL2
OSWindow-SDL2-Examples

After that, the following doIt is required in a playground to start
receiving events:

SDL2Constants initialize.
SDL_Event initialize

Best regards,
Ronie

2016-04-10 3:15 GMT-03:00 p...@highoctane.be :

> There is joystick support in 4.0, but not in Unix (plugin looks pretty
> empty).
>
> Smalltalk vm listBuiltinModules select: [ :each | each beginsWith:
> 'Joystick' ].
>
> JoystickTabletPlugin VMMaker-oscog-nice13154.314
>
> So, it is all in the InputEventSensor
>
> Check for senders of primReadJoystick:
>
> --> joystickXY:, joystickButtons: ...
>
> Phil
>
>
> On Sun, Apr 10, 2016 at 1:18 AM, Stephan Eggermont 
> wrote:
>
>> On 09-04-16 15:24, Carolina Hernández wrote:
>>
>>> I couldn't find any direct way to use a joystick in Pharo, if someone
>>> knows
>>> about one, I'd like to integrate it to my code.
>>>
>>
>> https://github.com/Geal/Squeak-VM/tree/master/platforms/Mac%20OS/plugins/JoystickTabletPlugin
>>
>> Refers to a joystick plugin for squeak. I don't know if that is in the
>> current distribution
>> (it doesn't seem to be), so you might ask on the vm-dev list about it. I
>> haven't looked
>> at it, so it could be for a RS-232 based joystick instead of something
>> more useful with
>> a modern pc.
>>
>> Can't SDL2 be used with a joystick?
>>
>> Stephan
>>
>>
>>
>>
>>
>>
>

Re: [Pharo-users] New project: AR.Drone communication API in Pharo

[Ronie Salgado]

>
> Can't SDL2 be used with a joystick?


It can be used. Although, joystick support was not very well integrated
into OSWindow because joystick events are not being sent into a specific
window. Now I am doing a cleanup on the joystick support, by sending the
event to all the windows. I will publish an example soon.

In SDL2 there are also two APIs for joysticks, the Joystick API and the
GameController API (Joystick + layout mapping). I originally made the
bindings only for the Joystick API. I just made the bindings for the
GameController API, which is more useful, since you do not have to worry
about different joystick layouts. There are also some events for detecting
when a joystick is connected or disconnected from the machine which I am
adding.



2016-04-09 20:18 GMT-03:00 Stephan Eggermont :

> On 09-04-16 15:24, Carolina Hernández wrote:
>
>> I couldn't find any direct way to use a joystick in Pharo, if someone
>> knows
>> about one, I'd like to integrate it to my code.
>>
>
> https://github.com/Geal/Squeak-VM/tree/master/platforms/Mac%20OS/plugins/JoystickTabletPlugin
>
> Refers to a joystick plugin for squeak. I don't know if that is in the
> current distribution
> (it doesn't seem to be), so you might ask on the vm-dev list about it. I
> haven't looked
> at it, so it could be for a RS-232 based joystick instead of something
> more useful with
> a modern pc.
>
> Can't SDL2 be used with a joystick?
>
> Stephan
>
>
>
>
>

Re: [Pharo-users] Pharo for Data Visualization

[Ronie Salgado]

You need a modern graphics card. Open source graphics drivers are not
supported because there are very behind in their implementations of OpenGL.


2015-11-24 17:28 GMT-03:00 Volkert :

> But not on my linux box  ubuntu 14.04 :-(
>
>
>
>
> On 24.11.2015 21:03, Alexandre Bergel wrote:
>
> Woden works in Pharo 5.0
> I have just tried.
>
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
> On Nov 24, 2015, at 3:15 PM, Volkert < 
> volk...@komponentenwerkstatt.de> wrote:
>
> Cool ...
>
> Which Pharo Version? I  tried Pharo 4.0 and got this error:
>
> 
>
>
> On 24.11.2015 12:50, Alexandre Bergel wrote:
>
> Do we have a tutorial? i found only http://woden.ronie.cl.
>
> What about mouse control and object selection. It that possible?
>
>
> Yes.
>
> To load Woden:
>
> Gofer new smalltalkhubUser: 'ronsaldo' project: 'Woden'; package:
> 'ConfigurationOfWoden'; load. (Smalltalk at: #ConfigurationOfWoden)
> loadBleedingEdge.
>
> Try:
> =-=-=-==-=-=-==-=-=-==-=-=-=
> v := RWView new.
>
> 1 to: 100 do: [ :i |
> e := RWCube element.
> e when: RWMouseButtonDown do: [ :ev |
> ev element shape color: WDColor green.
> ev element changed.
> ].
> v add: e.
> ].
> RWXZGridLayout on: v elements.
> v addInteraction: RWMouseKeyControl.
> v camera position: (WDVector3 x: 0.0 y: 0.0 z: 3.0).
> v open
> =-=-=-==-=-=-==-=-=-==-=-=-=
> Use the keys A S D W and the moose to navigate. Click on cube to make them
> green
>
> 
>
> Cheers,
> Alexandre
>
>
>
>
> BW,
> Volkert
>
> On 22.11.2015 21:10, Alexandre Bergel wrote:
>
> We have also put quite some effort on Woden, a 3d engine for Pharo…
>
> Cheers,
> Alexandre
>
>
> On Nov 22, 2015, at 2:56 PM, Dimitris Chloupis < 
> kilon.al...@gmail.com> wrote:
>
> its possible via my Ephestos project, to render to video or real time but
> the project is still very much a WIP. Its doable but require some python
> knowledge and knowledge of Blender UI and API. I will be making a true
> Pharo API for it fairly soon but as you can imagine these things take time.
>
> On Sun, Nov 22, 2015 at 6:35 PM Volkert 
> wrote:
> Is this possible with Pharo?
>
> http://www.asterank.com/3d/
>
> BW,
> Volkert
>
>
>
>
>
>
>
>
>
>

Re: [Pharo-users] VM crash on Ubuntu 14.04

[Ronie Salgado]

Hi Johan,

Perhaps I can try to help you debugging with gdb. Are you using a 32 bits
or 64 bits Ubuntu ?
We should start by building a debug Pharo VM. Do you have some time during
Monday or Wednesday in your office?.

Greetings,
Ronie

2015-10-31 22:00 GMT-03:00 stepharo :

> Why do you say that johan?
> Everybody is busy and has its own agenda. I'm sure that esteban would love
> to have the time
> to just wait for helping people. This is not the case and the dragons he
> is fighting against are
> quite large and venomous.
> So the suggestion of Ben is good because else I do not see how people can
> help you.
>
> Stef
>
> Le 24/10/15 12:32, Johan Fabry a écrit :
>
> Ben, thanks for replying but since no VM guys are following up on this,
>> apparently, it does not make much sense for me to go this way.
>>
>> Guys, am I to assume there is not help for me on this topic?
>>
>> On Oct 23, 2015, at 11:03, Ben Coman  wrote:
>>>
>>> On Thu, Oct 22, 2015 at 2:25 AM, Johan Fabry 
>>> wrote:
>>>
 Hi all,

 I am having some unpleasant experiences on Ubuntu 14.04 (experimenting
 with Live Robot Programming on PhaROS). The VM crashes after a random
 amount of time (< 25 minutes), with no clear sequence of steps on how to
 reproduce the crash. I am using Pharo 4 (Pharo 40622 as installed by
 PhaROS) + Roassal which required an install of libcairo2:i386 . VM version
 details below.

 There is no printout on stdout, and the debug.log does not contain
 recent entries (timestamp is always some minutes before the actual crash
 happens).

 Is this a known problem? If so, how can I fix it, and if not how can I
 provide more debugging info?

 Thanks in advance!

>>> I'm not much help since I haven't done these myself, but just some
>>> ideas (maybe someone can add more details)
>>> * compile and run a debug vm
>>> * trace all function calls, http://tinyurl.com/gdb-trace-all
>>>
>>>
>>
>> ---> Save our in-boxes! http://emailcharter.org <---
>>
>> Johan Fabry   -   http://pleiad.cl/~jfabry
>> PLEIAD and RyCh labs  -  Computer Science Department (DCC)  -  University
>> of Chile
>>
>>
>>
>>
>
>

[Pharo-users] Basic Woden Loading tutorial

[Ronie Salgado]

Hi,

I started writing a basic woden loading tutorial: http://woden.ronie.cl/

Please, bear in mind that this is an early draft, so expect lot of mistakes.

Greetings,
Ronie

Re: [Pharo-users] Woden?

[Ronie Salgado]

Hi Hilaire,

I am not able to reproduce your problem. Can you try testing with the
following image and VM?: http://ronie.cl/Woden/woden-a01-linux.zip

Greetings,
Ronie

2015-07-20 8:00 GMT-03:00 Merwan Ouddane merwanoudd...@gmail.com:

 On lun., 2015-07-20 at 18:41 +0800, Hilaire wrote:
  Le 20/07/2015 05:45, stepharo a écrit :
   merwane
  
   could you also publish the files you used?
   I think that this would be good to have a resource so that people can
   fully
   redo all the exercises.
 
  I understand Woden is still at early stage of development, so not much
  documented, that's ok.
  But my problem seems related to something else than missing resources,
  and I don't know what's wrong.
 
  I have an error at the VM level, even using the latest pharo vm.
  See screenshot of error at:
  http://permalink.gmane.org/gmane.comp.lang.smalltalk.pharo.user/20773
 

 Weird...
 Seems like you don't have the Nativeboost trait TNBMemoryAccessors

  Thanks
 
  Hilaire
 

Re: [Pharo-users] Woden?

[Ronie Salgado]

 May I suggest you add a note on SmalltalkHub about needed Pharo version
 (I just added one in DrGeo page;)

Done.


2015-07-20 10:53 GMT-03:00 Hilaire hila...@drgeo.eu:

 Le 20/07/2015 21:01, Ronie Salgado a écrit :
  I am not able to reproduce your problem. Can you try testing with the
  following image and VM?: http://ronie.cl/Woden/woden-a01-linux.zip

 Ronie,

 Ok, your image works out of the box, with the shipped VM or latest VM
 download from pharo.org.
 I see your image is Pharo4.0. I was using 3.0, probably because I see
 some #3.0 for opengl.
 May I suggest you add a note on SmalltalkHub about needed Pharo version
 (I just added one in DrGeo page;)
 I will try to install in a fresh 4.0, just to be sure.

 Thanks

 Hilaire

 --
 Dr. Geo
 http://drgeo.eu
 http://google.com/+DrgeoEu

Re: [Pharo-users] Woden-Roassal pharo5 inspector bugs

[Ronie Salgado]

There are not news yet, but I will try to take a look on this. This is
actually anoying, so I will find a workaround soon.

2015-06-17 18:16 GMT-03:00 Natalia Tymchuk natalia.tymc...@unikernel.net:

 Are there any news?

  On 06 May 2015, at 13:00, Alexandre Bergel alexandre.ber...@me.com
 wrote:
 
  Apparently moose will soon move to Pharo 5. Maybe next week or so.
 
  Alexandre
 
 
 
  Le 6 mai 2015 à 04:34, Lusa Nicolas nicolas.l...@usi.ch a écrit :
 
  Hi,
 
  thanks for the quick answer, I'll switch back to pharo4 for the moment.
 
  Cheers,
  Nicolas
 
 
 

Re: [Pharo-users] Use array of float to GPU memory

[Ronie Salgado]

 sounds interesting, but what is the context of this?  Is this built
 into Pharo, what version?  Or what library?

Those methods are not built into Pharo. They are present in the OpenCL
bindings ( http://smalltalkhub.com/#!/~ronsaldo/OpenCL ), and I don't think
they are very efficient in my opinion.

See my answer to the original question for more information.

Greetings,
Ronie

2015-06-12 22:22 GMT-03:00 Ben Coman b...@openinworld.com:

 On Fri, Jun 12, 2015 at 10:38 PM, cheikhou cheikho...@gmail.com wrote:
 
  Finally I have found a useful method called asCLFloatArray that
 converts
  float arrays of CPU as CL float arrays of GPU. The reverse action is
  possible by using asFloatArrayFromCL.(from GPU to CPU memory)

 sounds interesting, but what is the context of this?  Is this built
 into Pharo, what version?  Or what library?
 cheers -ben

Re: [Pharo-users] Woden - Rotate an Object from absolute referential

[Ronie Salgado]

Hello Merwan,

Currently is not possible because the only way to represent rotations is to
use a matrix. I have to add support for quaternions, which gives me an
opportunity to also add Euler angles.
When I add support for Euler angles, you wil be able to do what you want
easily.

Currently, you have to use node orientation: (WDMatrix3 xrot: angle) to
achieve what you are trying to do.

Greetings,
Ronie

2015-05-04 11:55 GMT-03:00 merwanoudd...@gmail.com:

 Hello everyone,

 I am currently making a little demo with woden and I would like to rotate
 a cube, not from the relative referential but from the absolute one (
 rotate X always rotate in the same direction even if I previously have
 rotated Y ).

 What currently happens is that when I rotate the cube, the referential
 rotates as well...

 Does anyone know how to counter this ?

 Thanks
 Merwan

Re: [Pharo-users] Pharo-Launcher Windows 8.1

[Ronie Salgado]

I think that we should have a Pharo-bugs mailing list that gets notified
for each bug that is filled in fogbugz

2015-03-21 4:54 GMT-03:00 kilon alios kilon.al...@gmail.com:


 Bottom line is that reporting a problem in the mailing list first makes
 much more sense because

 a) Way more likely to get an answer
 b) Avoid adding to the list on non existent bugs in fogbugz
 c) Bring the bug if it really exists to the attention of more people,
 hence increase that chance of the bug getting a fix.
 d) Far easier to remind people of the bug later on by just bumping on the
 thread which everyone on the list will get notified compared to fogbugz
 that if you are not subscribed to a bug you wont be notified.

 So yes definitely want to discourage people from starting from fogbugz.
 Also personally I dont like fogbugz because its so isolated.

 On Sat, Mar 21, 2015 at 2:15 AM, Ben Coman b...@openinworld.com wrote:







 On Fri, Mar 20, 2015 at 7:04 PM, Sebastian Heidbrink shei...@yahoo.de
 wrote:

 Hi,

 I recently mentioned issues with the installation of the pharo-launcher
 on Windows 8.1

 Turned out I just needed to download the PharoV30.sources file and
 place into the installation folder.

 Now everything seems fine.

 Is this also a topic for the pharo bug list, or is there another place
 where I can mention this?

 Sebastian



 On Sat, Mar 21, 2015 at 1:46 AM, kilon alios kilon.al...@gmail.com
  wrote:

 there is also an options in settings that downloads and install sources
 for you automagically.

 This is the right place to report issues and if you are 100% sure its a
 bug you can report it also in the pharo fogbuz



 100% is a bit strong and sounds a bit discouraging :).As long as you
 can list the detailed steps reproduce the problem, then its worth putting
 in fogbugz.  However fogbugz has a lot of old issues and sometimes a new
 issue is like a lost tree in the forrest.   Its generally beneficial if you
 socialise it on the mail list as well.

 A good workflow is:
 1. Search fogbugz for similar issues.
 2. Ask on the mail list if its a known issue, or if you should create a
 new one. List your steps to reproduce and ideally a solution.
 3. Log a new issue on fogbugz, copying the mail list discussion there.
 Paste the link back to the mail list thread.

 So in general:
 * the mail list has a broader audience and gets a better triage
 * fogbugz tracks history to ensure it doesn't get lost - and nothing
 happens except what goes through the tracker.  (btw, set Project=Launcher)

 cheers -ben

Re: [Pharo-users] Building 3D shapes in Roassal with interaction. Unexpected behaviour?

[Ronie Salgado]

Hello Nicolas,

Thanks for pointing this bug. I just fixed it in Woden-Core-RonieSalgado.64
. Can you try again?

Greetings,
Ronie

2015-01-28 10:40 GMT-03:00 Nicolas Lusa nicolas.l...@usi.ch:

 v := RWView new.

 e := (RWPyramid new) element.
 e on: RWMouseButtonDown do: [ :ev |
 ev element shape color: WDColor blue.
 ev element changed.
 ].
 v add: e.

 g := (RWCube new) element.
 g on: RWMouseButtonDown do: [ :ev |
 ev element shape color: WDColor green.
 ev element changed.
 ].
 g translateBy:(WDVector3 newX: 4.0 y: 0.0 z: 0.0).
 v add: g .

 f := (RWCylinder new) element.
 f on: RWMouseButtonDown do: [ :ev |
 ev element shape color: WDColor red.
 ev element changed.
 ].
 f translateBy:(WDVector3 newX: 2.0 y: 0.0 z: 0.0).
 v add: f.

 v addInteraction: RWMouseKeyControl.
 v camera position: (WDVector3 x: 0.0 y: 0.0 z: 3.0).
 v open.

Re: [Pharo-users] Polygons in woden

[Ronie Salgado]

Hi Nicola,

Sorry for not answering before. I have to improve my mail filters.

As for the shadows, currently only the spotlights can cast shadows. I have
yet to implement shadow mapping for directional lights. As for point light,
I won't be implementing them in the near future, because they are very
expensive. Currently you can simulate a point light casting shadows by
using 6 spotlights with different orientations but in the same point.

Also, you have to use deferred shading if you need shadows
(WDFPSSimpleExample8  #initializeSceneRenderer)

As for the polygons, Woden cannot render arbitrary polygons. Only points,
lines, triangles and quads because that is what the graphics cards support.

For an arbitrary polygon, you have to perform some kind of triangulation.
If the polygon is convex, this is trivial, but if the polygon is concave
this is hard (the algorithm missing is a Restricted Delaunay Triangulation).

For drawing a convex polygon, you have to do something like this:

positions := Some Collection ..

builder newTrianglesScope.

Add the positions.
positions do: [:i |
  builder addP: 
].

Add the indices
3 to: positions size do: [:i |
  builder addI1: 1 i2: i - 1 i3: i
].

What this code does is to generate a triangle fan (
http://en.wikipedia.org/wiki/Triangle_fan  ) which is a simple way to
triangulate a convex polygon.

I think that I should add a method to the geometry builder.

Greetings,
Ronie



2014-10-28 11:33 GMT-03:00 Nicolas Lusa nicolas.l...@usi.ch:

 Hi everyone,

 I am working on some 3d representation and I am trying to draw 3D polygons
 with woden. I actually manage to make the walls but I still have to
 implement top and bottom parts which are not so simple since the shape can
 be really different from case to case.
 How I am actually doing it is with: WDGeometryBuilder adding vertices with
 addP:  N:  C:  TC: messages and with addQuadI1: i2: i3: i4:
 Furthermore I have some issues with the shadows which actually don't
 appear.

 You can see a current polygon created with the code that I made in the
 attached image. (also notice the shadows are missing as well as the bottom
 and top part of the polygon).
 [cid:E6905B6F-F5CA-447D-A42D-BA1604AC7F5A@mobile.usilu.net]
 Now my question is: is there already something that makes those polygons
 or does anyone have any hint on how to make the top part with woden?

 Thannks in advance.

 Cheers,
 Nicolas

Re: [Pharo-users] FFI structs

[Ronie Salgado]

 Ronie is working on unifying all the api and proposing one syntax
 mechanism for
 - nativeBoost back-end
 - FFI
 and may be Alien

 I had a skype session with Eliot the last. He taught me about the callback
mechanism and I am actually going to use Alien for the callbacks, by
adapting it to perform the marshalling into the UFFI/NativeBoost types.

In the future, I am planning in using Lowcode to perform the whole callback
process, but now for simplicity I am just going to piggy back in Alien.

I still have to finish the callout by fixing a complicated bug. With Eliot
we discussed a workaround for this bug. I haven't implemented those
workaround yet, because  I have been a bit busy with my university studies.

As long as we keep what is working, ahem, working. I now depend on quite a
 couple of FFI related libs.

 What I need is an easy FFI wrapping tool, like
 https://github.com/ronsaldo/swig. Is UFFI going that way?

Well, I made the swig adaptation for NativeBoost. Making it for the UFFI is
actually something trivial. So, we are going to have a powerful FFI and a
binding generator for it.

The only problem with Swig, is that the bindings generated by it are not
perfect, because it exposes the exact same C API. A C library that uses
some kind of object model, cannot be exposed in a clean object oriented way
cleanly by a generic automatic tool.

The FFI situation is not good and we know we should improve it.

For the record, the current FFI situation can be traced to the historical
origins of Smalltalk and even Squeak. The original Smalltalk was an actual
operating system, and Squeak was also made as an operating system. Because
of this, they were not designed to interact with other languages.

Getting a perfect FFI is going to take a lot of time, because of other
problems, such as Multi-threading and the mandatory use of non-blocking IO.
Fortunately, Eliot made a way to have a threaded FFI, in which a single
thread owns the VM at a single time. With this threaded FFI we can have
things such as a callback from a different thread, which is required by
some libraries such as the sound API of SDL2.

Of course the UFFI is going to support this threaded FFI in some point of
time. To support the threaded FFI I only have to pin/unpin some object, and
call two VM functions, disownVM() and ownVM().

As for getting some actual parallelism in Pharo, this is something that I
think is going to take a big amount of time. For now the best thing we can
do is to use OpenCL. This week I have been doing some experimenting in
making an API for linear algebra, that uses OpenCL to perform computations
in parallel. Later I will publish a video.

Greetings,
Ronie

2014-10-31 19:23 GMT-03:00 Alain Rastoul alf.mmm@gmail.com:

 Hi Annick,

 you can't pass smalltalk strings or objects to ffi as parameters,
 you have to allocate the buffer member of your structure
 on the external heap ( plus to avoid being gc'd before ffi call)
 with ExternalAddress allocate: your buffer/string size +1 for string null
 termination
 fill your buffer with byteAt:put: method,
 and release this memory with free when you have finished.

 not sure, but you could try something like:

 s := '05:45' copyWith: (Character value: 0).
 a := ExternalAddress allocate: s size.
 s asByteArray withIndexDo: [ :b :i | a byteAt: i put: b  ].
 myStruct time: a.
 ... call your ffi ...
 a free


 Regards,

 Alain

 Le 29/10/2014 11:59, Annick Fron a écrit :

  I I have a C struct with a char*

 struct result {
 char* time }

 I define an ExternalStructure in FFI , with one field of type char* (note
 that the syntax char [5] is not accepted ! ).

 defineFields generates the accessors time and time:

 If I use
 time: ’05:45’

 I get an error.
 How do I set a string value in an ExternalStructure ?

 Annick

Re: [Pharo-users] Calling Pharo from C

[Ronie Salgado]

 FFI - Not sure
 Alien - Not sure
 NativeBoost - Yes

One thing is receiving a callback from C. In this case, NativeBoost is the
one with the worst end-user API.

Another thing, is being able to embed the VM in a C application, and then
call the VM explicitly from the application. In this case, there is not
efficient support at all.

The closest thing would be spawning the VM in a different process, and then
perform calls via a socket.

Greetings,
Ronie

2014-09-19 20:42 GMT-03:00 Pierce Ng pie...@samadhiweb.com:

 On Thu, Sep 18, 2014 at 10:05:51PM +0200, Annick Fron wrote:
  Is it possible to call pharo from C ?

 FFI - Not sure
 Alien - Not sure
 NativeBoost - Yes

 Simple example here:

   http://www.samadhiweb.com/blog/2014.08.02.c.callback.smalltalk.html


 Pierce

Re: [Pharo-users] [gsoc-mentors] GSoC: call for ideas

[Ronie Salgado]

I am proposing the following as a student:

Project idea

Name: Unified Foreign Function Interface
Skill level: Advanced
Possible Mentors: Igor Stasenko / Esteban Lorenzano
Name of the Student: Ronie Salgado

Description:

Because NativeBoost has problems with portability and cannot be used
anywhere(iOS), one proposal is making a modular unified foreign function
interface. This UFFI should support multiples backends, a portable function
calls specification, portable easy to use callbacks support, and portable
foreign resources management.

Full Description Document:
http://users.dcc.uchile.cl/~rsalgado/uffi-fourth-draft.pdf



2014-02-13 12:21 GMT-03:00 teso...@gmail.com teso...@gmail.com:

 Project idea

 Description: Enhance refactorings with type information
 Skill level: Advance
 Possible Mentors: Guillermo Polito / Esteban Lorenzano / Santiago
 Bragagnolo
 Name of the Student: Pablo Tesone
 Keywords: tools, refactoring, code completion, type inference.

 Description:

 During the development of a program in any programming language, the IDE
 has a very important role. It will never replace the knowledge of the
 programmer but it can make his life easier.
 As Smalltalk doesn't have explicit type information, the IDE can not
 perform the same mechanisms that are present in IDE like Eclipse or
 Intellij IDEA. These mechanisms can be very useful.
 The idea of this project is to add type inference mechanisms to try to
 provide more information to the refactoring and code completion tools.
 It is important to say that the idea is not to check types or correct the
 program, but to allow the programmer to have more information.



 On Thu, Feb 13, 2014 at 12:06 PM, Usman Bhatti usman.bha...@gmail.comwrote:

 [Anne Etien could not post this msg on the mentors list I m forwarding it
 on her behalf].

 Title: FAST JavaScript model

 Level: advanced

 Possible mentor: Anne Etien

 Possible second mentor: Nicolas Anquetil or Yuriy Tymchuk

 Description:
 For in depth source code analysis a support of abstract syntax trees is
 required. FAST is an abstract syntax tree extension for FAMIX meta-model
 that is used by Moose technology. The goal of this project is to create
 a JavaScript version of FAST.

 Technical Details:
 As programming languages are different, their AST representations are
 different too. FAST model aims for creation of as generic as possible
 core that can be extended for different languages. Also the structure of
 a model allows creation of generic algorithms like symbol resolution,
 metrics calculation and rule checking that will work for any language.
 Prototypes of FAST for Smalltalk and Java are already implemented.
 During the project a student will implement the JavaScript model. More
 detailed information about FAST is provided in the Moose day
 presentation: http://youtu.be/dRr3WHOD3x4

 Benefits to the Student:
 The student will gain a deep understanding of a JavaScript syntax and
 abstract syntax tree model. He will also learn about PetitParser
 framework, and gain knowledge about software modeling and analysis.

 Benefits to the Community:
 Community will get a FAST model for JavaScript that can be used for
 software assessment with Moose. Also this model can be used later in PhD
 projects such as automation of source code translation. With this third
 model, the community will have raw material to real think and improve
 generic algorithms based on AST.


 On Tue, Feb 11, 2014 at 10:42 AM, Damien Cassou 
 damien.cas...@gmail.comwrote:

 Hi fellow Pharo hackers,

 ESUG, the European Smalltalk User Group, is applying for this
 year's Google Summer of Code.  As you probably know, the Summer
 of Code provides the opportunity to fund students to work during
 the summer on Pharo.  Please reply to this
 email (be sure to use Reply to all) if you have ideas you
 would like to propose.

 Please include a summary of the project and links to web pages
 that can help prospective students to write their application.
 Please also include the following information:

 - if applicable, other dialects that you would be willing to
   mentor this project for

 - the skill level

 - name of the mentor(s), email addresses, and possibly any IRC
   network/channel/nickname where they can be found.

 Thanks for contributing to ESUG's Summer of Code application!

 --
 Damien Cassou
 http://damiencassou.seasidehosting.st

 Success is the ability to go from one failure to another without
 losing enthusiasm.
 Winston Churchill

 --
 You received this message because you are subscribed to the Google
 Groups Smalltalk GSoC mentors group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to smalltalk-gsoc-mentors+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.


  --
 You received this message because you

[Pharo-users] How images can be loaded

[Ronie Salgado]

Hello,

I would like to know how I could load .png image into pharo, and being able
to access to their pixel data for manipulation or display it.

Greetings,
Ronie Salgado