Re: [Pharo-users] Any perspective of Woden in Pharo 6.1/7 ?????
> > 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] Calling Pharo from C
> 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 : > 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] FFI structs
>
> 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 :
> 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: 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] Polygons in woden
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 : > 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] Building 3D shapes in Roassal with interaction. Unexpected behaviour?
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 : > 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] Pharo-Launcher Windows 8.1
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 : > > 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 wrote: > >> >> >> >> >> >>> >>> On Fri, Mar 20, 2015 at 7:04 PM, Sebastian Heidbrink >>> 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 >>> 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] Polygons + Skybox in woden?
this requires heavy support for pointers a la C. Best regards, Ronie Salgado 2015-04-16 18:24 GMT-03:00 Alexandre Bergel : > > Uhh.. > > > > I Woden still developed? Because I thought that Object Profile was > working on it. Otherwise maybe we should switch to the CodeCity engine… it > seems to have more “support”. > > Ronie? > > Alexandre > > > > >> On 16 Apr 2015, at 15:11, Alexandre Bergel > wrote: > >> > >> No idea, but let us know! > >> > >> Alexandre > >> -- > >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >> Alexandre Bergel http://www.bergel.eu > >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >> > >> > >> > >>> On Apr 16, 2015, at 4:41 AM, Lusa Nicolas wrote: > >>> > >>> Hello, > >>> > >>> I am Nicolas Lusa from university of Lugano and I am working on my > master thesis with the supervision of Yuriy Tymchuk. > >>> Right now I am working with woden and I am trying to build polygons. > >>> Question1: Is it possible somehow to build polygons in woden? > >>> > >>> If not: > >>> I know woden is based on OpenGL and I also know that in OpenGL is > possible to draw polygons with GL_POLYGON and a given array of points. > >>> Question2: How could I use GL_POLYGON through woden for my purpose? > >>> > >>> Moreover, I would like to put some sort of skybox in my scene. > Apparently it's not possible yet, so my question is how could I do that? > >>> > >>> Thanks in advance. > >>> Cheers. > >>> Nicolas > >> > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >
Re: [Pharo-users] Woden-Roassal 3d object rotations
Hello Mr. Lusa, Sorry for not answering earlier, I added the missing support for the rotations by adding some methods that changes the internal scene node orientation. I also did a small refactoring in the support for orientation, because I received email with an implementation of quaternions that I have review and integrate during the week. Try the following in the playground: v := RWView new. element := RWCube element. element rotateByXDegrees: 60. v add: element. v open. Best regards, Ronie 2015-04-27 3:55 GMT-03:00 Lusa Nicolas : > Hello mr. Bergel, > > I actually have done something really simple. On the construction of a > cube shape in WDGeometryBuilder I simply made a method looking as follows: > WDGeometryBuilder>>#addCubeWithWidth: height: depth: rotatedBy: . > In the method I simply use the angle to compute the rotation when creating > every single triangle (rotating every point of such triangle with respect > to the y axis). > It would work smoothly if only few shapes would have been instantiated but > unfortunately this results in a severe drop of performance since a new > shape is created for every instance of an object (because the angle > rotation is different for each shape). > If you still want the code I wrote for such rotation I can provide it to > you, but probably that's not how proper rotations should be performed in > woden. > > Hopefully we can find a better solution that doesn't influence > performance in such way. > > Cheers, > Nicolas > > P.S. I apologize for the misleading subject of the mail. I am not using > Roassal3d but I am using a package called Woden-Roassal, which works almost > exactly like Roassal3d (in fact I guess they are related somehow), that is > in the Woden project as default. A more appropriate e-mail subject would > have been: Woden-Roassal (3d object rotations). > > On Apr 24, 2015, at 10:49 PM, Alexandre Bergel > wrote: > > Hi Lusa, > > Well spotted! > I worked on the connection Woden <—> Roassal3d. I should be able to hook > your rotation into roassal. Can you provide your fix for the rotation > please? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > On Apr 22, 2015, at 9:07 AM, Lusa Nicolas wrote: > > Hi, > > I am still working with Woden, in particular with Woden-Roassal and I > noticed that rotations on objects are missing (I feel that this is weird > that it doesn't have such feature so I am not excluding that I can be wrong > but I didn't manage to find anything in the code to rotate objects). > > Now if I would like to rotate objects it wouldn't be too bad if I were > using Woden at his "lowest layer" but I am actually building cubes with > Woden-Roassal and there I get lost. > > I already made some rotations on Woden built arbitrary objects, now I > would like to extend it to objects built from Woden-Roassal but I honestly > miss on finding the connection between the two. > > I saw that the base shape is built in: RWCube>>#createBaseShapeNode, I > would be able to build a rotated shape from there but that would result in > all shapes being rotated in such way since in > RWSimpleShape>>#buildRenderableFor:view: when we select the shape: > baseShape := aView baseShapeNodeNamed: self baseShapeName ifAbsentPut: [ > self createBaseShapeNode ]. > we would get back the previous base shape defined. > > Any suggestions on how to do it? > > Cheers, > Nicolas > > > >
Re: [Pharo-users] Woden - Rotate an Object from absolute referential
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 : > 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] Using VirtualGPU
Hi all, Sorry for answering very late, I am busy in ICSE where tomorrow I have to defend my poster for the Student Research Competition. The topic is profiling over the OpenCL bindings. We are looking at the code of OpenCL and VirtualGPU done by Ronnie. > What we have understand until now : > - OpenCL package : low-level stuff to be able to interface OpenCL > kernels with Pharo > - VirtualGPU: high-level API on top of OpenCL in order to ease the > task of people who wants to use OpenCL. VirtualGPU provide high-level > operations on matrix and image at the moment. This is correct. @Ronie: What is not clear at the moment in our mind : when you build a > VirtualGPU program with the DSL, do you have the overhead of > communications every time you execute a VirtualGPU instruction or all > the the instructions are sent at the same time and run on the GPU ? > The DSL, is actually an abstraction over the OpenCL API. Each operation, is stored in a simple intermediate representation, that is used to call a single OpenCL kernel. There is no overhead in terms of memory transfers between intermediate operations, because there kept in the GPU the whole. There is an overhead in terms of kernel dispatching. For example, the expression a + b * 0.5 in the VGPU DSL is interpreted as the following pseudo code: temp := opencl invokeKernel: 'add' a with: b. temp2 := opencl invokeKernel: 'mulScalar' temp with: 0.5. A custom crafted code would do something like this: temp := opencl invokeKernel: 'addAndMulScalar' with: a with: b with: 0.5 The VGPU does not do the latter for simplicity. Currently, it does not generate any kind of OpenCL C code. It works by composing simple functions. Perhaps, in the future I will add a code generation step for optimization. Another problem, is the proliferation of intermediate buffers. There are some samples that avoid using intermediate buffers by using add:into: instead of +. The into buffer is just where the result is going to be placed. Look into VirtualGPUSamples >> #imageChangedForGradient, VirtualGPUSamples >> #imageChangedForGradientOptimized , VirtualGPUSamples >> #imageChangedForGradientOptimizedMore . > In our context, for building a GSSA algorithm, I guess we just have to > combine same VGPU instructions (matrix computations) but for doing SPH > simulations, we will have to provide our own instructions. Is there > any documentation in order to add own kernel and instructions ? > There is not documentation. We should have some tool like doxygen so that I can write the documentation when I am writing the methods. Anyway, I will document here for now. First of all, look at the existing kernels. For that, put this in a playground and do it (you need the GTInspector): EmbObjectBrowser openBrowser. That will open a browser that I use to edit the OpenCL C code. It does have some bugs, but it is better than editting a huge string in a smalltalk method. Lets look in VGPULinearAlgebraSources. There you will see the 'kernels' category and inside of it two methods: #matrixKernels' and #vectorKernels . If you look #vectorKernels , you will see just the OpenCL C code. If you now go to Nautilus, and look the VGPULinearAlgebraSources class, you will see that it is a subclass of EmbObjectContainer. vectorKernels and matrixKernels are Smalltalk methods. vectorKernels looks like this: vectorKernels ^ ' // Vector binary operations __kernel void floatVector_add(__global float *left, __global float *right, __global float *result) ... ' For an example, of actually invoking the kernel, you should look at the following methods: VGPUFloatMatrix >> #abs VGPUFloatMatrix >> #absInto VGPUFloatMatrix >> #discreteGradient VGPUFloatMatrix >> #discreteGradientInto As for the OpenCL package, it just provides bindings for the C OpenCL API. You can also use it if you want, but your are on your own :) . I made some experiments with GPU computing with JavaScript. I understood > that the computings are made forever inside the GPU, so you just throw data > and programs once and you let the GPU compute for you. Yet the problem is > to read the data once they are computed. With webGL it seems impossible, > with webCL it is possible and not easy. Hence the choice of openCL I guess. > > I relate here how I could compute the powers of a Markov matrix here: > http://revue.sesamath.net/spip.php?article651 (especially click on "webGL > sans three.js"). I also made some experiments here: > http://irem.univ-reunion.fr/spip.php?article797 (but they use three.js if > I remember well) I have been taking a look at those so called HTML5 WebGL technology. It does not convince me, since I am more interested in desktop application. I was thinking on making a 3D level editor in html5, js and webgl to test the technology, it seems to have many problems. The last week with Milton we found an easy way to draw a Morph into a Woden texture, so I am going to be using Pharo for the editor. The main problem that I
Re: [Pharo-users] Copy array of float to GPU memory
Hi Cheikhou, Sorry for the late answering. I needed to check some stuffs. But the problem is it works only with ByteArray objects. > When I load array of floats to GPU , data are modify and I don't know how > and why and results are wrong. What kind of error are you getting? a NativeBoost error or incorrect results? Since you were originally asking me about FloatArray or IntegerArray, I am assuming you are getting incorrect results or a segmentation fault. The OpenCL package is just a binding with a bit of object orientation to the OpenCL C library that I wrote manually. Those binding don't try to do a lot of magic when receiving a Pharo object. The OpenCL C API when allocating a GPU side buffer is expecting a size in bytes. According to the class comment in IntegerArray and in FloatArray, they are composed of 32 bits elements. So, when passing their size to OpenCL, you have to multiply them by 4. For an actual example, check the new tests that I just added to the OpenCL-Tests packages. I tried using IntegerArray and FloatArray, and it did work. It seems that you found the asCLFloatArray and the asFloatArrayFromCL methods, that are used to convert from an Array into a ByteArray and backwards. For completeness, I just added the following new methods. asCLInt16Array <-> asInt16ArrayFromCL asCLInt32Array <-> asInt32ArrayFromCL asCLInt64Array <-> asInt64ArrayFromCL asCLUInt16Array <-> asUInt16ArrayFromCL asCLUInt32Array <-> asUInt32ArrayFromCL asCLUInt64Array <-> asUInt64ArrayFromCL asCLDoubleArray <-> asDoubleArrayFromCL Unlike passing an IntegerArray or a FloatArray, these are method are creating a new array, looping over all elements and doing marshalling/unmarshalling. These methods can be very inefficient. Be careful when using them. Best regards, Ronie Salgado 2015-06-12 8:09 GMT-03:00 cheikhou : > Hello. > > I use OpenCL package developed by Ronie Salgado package to program on GPU. > When I initialize an array with ByteArray class and load data to GPU memory > it works without any problem. > > But the problem is it works only with ByteArray objects. > When I load array of floats to GPU , data are modify and I don't know how > and why and results are wrong. > > Please someone have any idea > First: how to load integer values upper than 255 (not possible with > ByteArray) > Second: use float arrays correctly in GPU memory. > > Thanks for your help. > > > > - > Cheikhou > -- > View this message in context: > http://forum.world.st/Copy-array-of-float-to-GPU-memory-tp4831970.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >
Re: [Pharo-users] Use array of float to GPU memory
> > 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 : > On Fri, Jun 12, 2015 at 10:38 PM, cheikhou 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 > >
[Pharo-users] How images can be loaded
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
Re: [Pharo-users] How images can be loaded
Thanks, It works very well. Greetings, Ronie Salgado 2013/11/22 Sven Van Caekenberghe > Hi Ronie, > > On 22 Nov 2013, at 19:00, Ronie Salgado wrote: > > > 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 > > Here is an example: > > '/Users/Sven/Desktop/test.jpg' asFileReference readStreamDo: [ :in | > (JPEGReadWriter on: in) nextImage asMorph openInWindow ]. > > Inspect the results of #nextImage or #asMorph to learn more, this code > actually opens the image in a window in Pharo. > > Regards, > > Sven >
Re: [Pharo-users] Roassal3D : MessageNotUnderstood:NBMSAAOffscreenDisplay
Dear Volkert, I just updated the configuration of Roassal 3D for it to load the baseline version of NBOpenGL, with the changes made. Its currently only been tested under Linux, so any feedback its appreciated. Greetings, Ronie Salgado 2013/12/19 Volkert Barr > Dear Ronie, > > i had no success with older versions. Please give my a short note, when > the "configuration browser way" works again. > > BW, > Volkert > > On 15.12.2013, at 00:30, Ronie Salgado wrote: > > > Hello, > > > > Try with version 118, from Monticello. > > That problem is produced because I had to made some changes to NBOpenGL, > for which I don't have commit privileges so I posted them on the pharo-dev > mailing list. > > > > Greetings, > > Ronie Salgado > > > > > > 2013/12/14 Volkert Barr > > Hello, > > > > i loaded Roassal3D from the Configuration Browser into a fresh Pharo 3.0 > Image. When selecting "3D IDE" (Roassal3D Easel??) from > > the tools-menu i got to the following error: > MessageNotUnderstood:NBMSAAOffscreenDisplay>>bindFramebuffer. > > > > Probably i forgot to load some other base packages. > > > > Pharo3.0 > > Latest update: #30644 > > Host: OS X 10.8.5 > > > > Any hints? > > Volkert > > > > > > > > -- > www.nivoba.de > > "The more complex an object, the larger the investment in learning to use > it, and the greater the resistance to abandon it." > > >
Re: [Pharo-users] [gsoc-mentors] GSoC: call for ideas
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 : > 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 wrote: > >> [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 >> wrote: >> >>> 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 >>> ne
Re: [Pharo-users] Woden-Roassal pharo5 inspector bugs
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 : > Are there any news? > > > On 06 May 2015, at 13:00, Alexandre Bergel > wrote: > > > > Apparently moose will soon move to Pharo 5. Maybe next week or so. > > > > Alexandre > > > > > > > >> Le 6 mai 2015 à 04:34, Lusa Nicolas a écrit : > >> > >> Hi, > >> > >> thanks for the quick answer, I'll switch back to pharo4 for the moment. > >> > >> Cheers, > >> Nicolas > >> > >> > > > > >
Re: [Pharo-users] Woden?
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 : > 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?
> > 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 : > 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 > > > >
[Pharo-users] Basic Woden Loading tutorial
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] VM crash on Ubuntu 14.04
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 >> >> >> >> > >
Re: [Pharo-users] Pharo for Data Visualization
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] New project: AR.Drone communication API in Pharo
> > 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] New project: AR.Drone communication API in Pharo
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&feature=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] [UFFI] Using a nested structure
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] [UFFI] Using a nested structure
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 :
> 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
> 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
>> 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 :
>>>
>>>> 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] OpenGLES2 binding available!
> > 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 OpenGLES2 is ready > :)http://sm
Re: [Pharo-users] Using a Unix filedescriptor in a FileStream?
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] Crash in Athens
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] Fwd: GSoC 2017: Pharo Consortium has been accepted as a mentor organization!
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] Editor with syntax highlighting awareness
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] Smalltalkers will, eventually, win. So says this old C++ programmer.
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 I have found out, it has not
>>> occurred to them as it
Re: [Pharo-users] [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)
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 > > >
Re: [Pharo-users] Namespaces (was Re: Behold Pharo: The Modern Smalltalk)
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] What next for Pharo vm?
> > > 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 > >
[Pharo-users] [ANN] Pharo Git Thermite Release
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] OpenGL minimum working example?
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] Git Thermite integration with Iceberg
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
