- Pharo-users - lists.pharo.org

Re: [Pharo-users] [Bulk] Re: Fwd: Fwd: Debris' Quuve - Technologies used

by stepharo

And BTW I would really like to see how we can do crude with magritte-described objects. Le 18/4/15 21:37, stepharo a Ã©crit : > > > Le 18/4/15 20:04, Yanni Chiu a Ã©crit : >> On Apr 18, 2015, at 2:18 AM, stepharo <stepharo(a)free.fr> wrote: >> >>> I found strange that not a single little improvements of Magritte >>> was necessary for the Qude project. >> Itâs not strange to me, because when working with Magritte 2, it >> seemed that almost everything I wanted to do had a hook method to >> override, or an obvious place to subclass or extend. So much so, that >> when I could not find the extension point, I thought it was my fault. >> What was missing was instance-based descriptions, which was added by >> the community in Magritte 3. > > :) > >> >> Given how well-factored Magritte 2 was, my deduction was that a lot >> of effort had already been done to extract out an open-source >> artefact, from whatever system drove itâs development. So, no >> surprise that few improvements to the core Magritte were needed. > > Ok so we have perfect software. Good to know. >>> Now if heavy users of open-source libraries do not enhance these >>> open-source libraries and keep their extensions >>> under close source then the open-source libraries will never make >>> progress and I will immensely sad. >> Given that Magritte is already well-factored for extensions, what >> tends to be written is exactly the custom code which you would not be >> releasing to open-source. > > but you see I did not use magritte since long time. It would be great > to have example of custom-code. > For example are relationships any useful. >> >> However, there might be a case for add-ons, such as Twitter Bootstrap >> support. As mentioned in another post, changing the Magritte >> API/interfaces at this point is tricky, because it would affect >> current users - thatâs the conundrum: success and wider adoption will >> constrain the evolution. > We have versions to help there. > >> The addition of instance-based descriptions was worth the (minor) >> pain of the transition, but what level of pain would be tolerable to >> add Bootstrap support, especially if youâre not using Bootstrap. > But we are talking about SeasideMagritte here? > I do not know because I do not have experience. > I was talking about magritte. > > > >

April 18, 2015

Re: [Pharo-users] [Bulk] Re: Fwd: Fwd: Debris' Quuve - Technologies used

by stepharo

Le 18/4/15 20:04, Yanni Chiu a Ã©crit : > On Apr 18, 2015, at 2:18 AM, stepharo <stepharo(a)free.fr> wrote: > >> I found strange that not a single little improvements of Magritte was necessary for the Qude project. > Itâs not strange to me, because when working with Magritte 2, it seemed that almost everything I wanted to do had a hook method to override, or an obvious place to subclass or extend. So much so, that when I could not find the extension point, I thought it was my fault. What was missing was instance-based descriptions, which was added by the community in Magritte 3. :) > > Given how well-factored Magritte 2 was, my deduction was that a lot of effort had already been done to extract out an open-source artefact, from whatever system drove itâs development. So, no surprise that few improvements to the core Magritte were needed. Ok so we have perfect software. Good to know. >> Now if heavy users of open-source libraries do not enhance these open-source libraries and keep their extensions >> under close source then the open-source libraries will never make progress and I will immensely sad. > Given that Magritte is already well-factored for extensions, what tends to be written is exactly the custom code which you would not be releasing to open-source. but you see I did not use magritte since long time. It would be great to have example of custom-code. For example are relationships any useful. > > However, there might be a case for add-ons, such as Twitter Bootstrap support. As mentioned in another post, changing the Magritte API/interfaces at this point is tricky, because it would affect current users - thatâs the conundrum: success and wider adoption will constrain the evolution. We have versions to help there. > The addition of instance-based descriptions was worth the (minor) pain of the transition, but what level of pain would be tolerable to add Bootstrap support, especially if youâre not using Bootstrap. But we are talking about SeasideMagritte here? I do not know because I do not have experience. I was talking about magritte.

April 18, 2015

Re: [Pharo-users] Pillar used directly from Pharo

by Cyril Ferlicot

Hi ! You can use it from Pharo but it's a little complicated if you want to add a configuration file (pillar.conf). I can't explain now because I'm at a ceremony but when I'll have time I'll add the list of the commandes ! Le samedi 18 avril 2015, Jan ValÃ¡Å¡ek <valasja7(a)fit.cvut.cz> a Ã©crit : > Hi there, > > I'd like to ask you, whether is here a way to use pillar internally, > directly from Pharo and how to use it properly. I have found some > tutorials how to use it from linux/windows command prompt, however, I'd > prefer to call it in my program in pharo. > > > > Something like this -> > ----------------------- > header := pillarHeaderObject new. //creating pillar objects directly > from my program > header text:'Title of my page'. > aPillarDocument add: header. //adding them to the whole document > object > > and finally > > aPillarDocument exportToLatex. //export the document > ---------------------- > > > > or I can just write the text in the pillar notation to "myTextObject" > and then call something like-> > ------- > pillarParseAndExportToLatex: myTextObject. > ------- > > Is here a way to do this? > > Thanks for your help :-) > John. > > -- Cheers Cyril Ferlicot

April 18, 2015

Re: [Pharo-users] [Bulk] Re: Fwd: Fwd: Debris' Quuve - Technologies used

by Yanni Chiu

On Apr 18, 2015, at 2:18 AM, stepharo <stepharo(a)free.fr> wrote: > I found strange that not a single little improvements of Magritte was necessary for the Qude project. Itâs not strange to me, because when working with Magritte 2, it seemed that almost everything I wanted to do had a hook method to override, or an obvious place to subclass or extend. So much so, that when I could not find the extension point, I thought it was my fault. What was missing was instance-based descriptions, which was added by the community in Magritte 3. Given how well-factored Magritte 2 was, my deduction was that a lot of effort had already been done to extract out an open-source artefact, from whatever system drove itâs development. So, no surprise that few improvements to the core Magritte were needed. > Now if heavy users of open-source libraries do not enhance these open-source libraries and keep their extensions > under close source then the open-source libraries will never make progress and I will immensely sad. Given that Magritte is already well-factored for extensions, what tends to be written is exactly the custom code which you would not be releasing to open-source. However, there might be a case for add-ons, such as Twitter Bootstrap support. As mentioned in another post, changing the Magritte API/interfaces at this point is tricky, because it would affect current users - thatâs the conundrum: success and wider adoption will constrain the evolution. The addition of instance-based descriptions was worth the (minor) pain of the transition, but what level of pain would be tolerable to add Bootstrap support, especially if youâre not using Bootstrap.

April 18, 2015

Pillar used directly from Pharo

by Jan ValÃ¡Å¡ek

Hi there, I'd like to ask you, whether is here a way to use pillar internally, directly from Pharo and how to use it properly. I have found some tutorials how to use it from linux/windows command prompt, however, I'd prefer to call it in my program in pharo. Something like this -> ----------------------- header := pillarHeaderObject new. //creating pillar objects directly from my program header text:'Title of my page'. aPillarDocument add: header. //adding them to the whole document object and finally aPillarDocument exportToLatex. //export the document ---------------------- or I can just write the text in the pillar notation to "myTextObject" and then call something like-> ------- pillarParseAndExportToLatex: myTextObject. ------- Is here a way to do this? Thanks for your help :-) John.

April 18, 2015

Re: [Pharo-users] [ANN] Pharo 4.0 is released!

by Gaurav Singh

Congrats to all the developers for the amazing work :)

April 18, 2015

Re: [Pharo-users] [ANN] Pharo 4.0 is released!

by Sean P. DeNigris

Offray wrote > Sean, if you're here, have you read Tracing the dynabook [1]? No, thanks for the link! I'll add that to my Dynabook library :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/ANN-Pharo-4-0-is-released-tp4819877p4820402.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

April 18, 2015

Re: [Pharo-users] Polygons + Skybox in woden?

by stepharo

Hi ronie > Sorry for not answering, this email got buried under my inbox. > > IIRC, Woden is built on modern GL techniques, and GL_POLYGON is > deprecated in 3.0, so I doubt it. > > By polygon, what do you mean?, an arbitrary concave polygon or a > convex polygon? For a convex polygon, you only need to use what is > known as a triangle fan. For a concave polygon, you need a constrained > Delaunay triangulation, which is an easy to explain but hard to > implement algorithm. I guess that GL_POLYGON only supports convex > polygons. > > For the convex case, take a look here: > http://en.wikipedia.org/wiki/Triangle_fan > I think that the code should be something like this; > > builder := WDGeometryBuilder ... > points := {}. > points do: [:p | builder addP: ...]. > indexBase = 1. > 3 to: points size: [:i | > builder addI: 1 i2: i - 1 i3: i3. > ]. Yes people should read and learn :). > > If you want the concave case, take a look into the incremental > Delaunay triangulation algorithm. Then, into adding the constrains > (edges of the polygon) to construct the constrained Delaunay > triangulation. Now, this is a 2D algorithm, so the points have to be > in a plane. Don even think on trying a 3D Delaunay triangulation, > because it is for volumes and not surface, and it is hellish. > > > I Woden still developed? > > Currently I do not have time to work in Woden, but when I get more > time, I will continue working on it. More time means after May, > because of studies and a paper that I am presenting in ICSE. JB is adding shadders :) and a ci server. He is improving the shadder versionning because he got blocked on mac. All the code we do for the Thales project will be pushed back into Woden. Thanks for this great software. > 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â. > > > Now, I do not want to add many more low level features to Woden, until > I get a production ready version of Lowcode/uFFI, which is required to > optimize some really performance critical sections of Woden. With > Lowcode I am getting C like pointers in the VM with a small overhead > in comparison with nbFloat32AtOffset: and nbFloat32AtOffset:put: . > Pointers and C structures are required to fill buffers with an exact > memory layout, which is required by OpenGL 2+ . Nice nice nice. > The alternative to Lowcode or the NativeBoost x86-32 assembler, is to > move significant parts to C++. Moving significant parts to C++ means a > huge loss of flexibility, and it means a completely different engine. > Completely different, because I have been reading about more modern > game engines, and better design patterns such as Entity Component System. > > Anyway, one of the first thing that I am going to do when coming > really back to Woden, is to move it to GitHub. By using git I can fix > some part of the native library dependency hell. Bullet is used for > physics it is written in C++, and I am definitely not going to rewrite > in Smalltalk. > > 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? > > > Skyboxes are in my TODO list. My biggest problem with sky-boxes are in > loading the cube map texture. A cube map texture is actually a single > texture that has six faces. The six faces of a cube. > > Skybox support requires loading a cube map texture, and then using a > special material for the sky with a special shader. > I am going to try getting a demo working in the weekend, it should not > be very complicated. It also gives me a good opportunity to rewrite > the shaders. I found a better way to embed shaders when working in the > VirtualGPU, by using the GTInspector. JB did you commit your changes? > > you want to reinvent all the effort ronie put in woden? > > It is more probably that the one reinventing and being successful > would be myself. Graphics programming is really hard, specially if we > are doing it in a completely dynamic language as Smalltalk or Pharo. I > have learned valuables lessons by reinventing my game/graphics engine > several time, and studying long time ago others game engines, such as > the good old Quake engine. Woden is not my first or second graphics > engine, I have already lost the count. I think it is about my > sixth/seven engine. And I still think that there's a lot of room that > I have improve, without rewriting everything. Excellent. Keep pushing. > > Do not expect to see a AAA game engine written completely in Pharo or > Smalltalk. The optimizations done in AAA engines simply cannot be done > in Smalltalk. They are designed with simple data structures that are > optimized to work well with CPU caches. There is also some heavy > inlining done by the C/C++ compiler. No garbage collection, just > manual and deterministic memory management. > > If you want to make a new engine, please be aware that the graphics > landscape is becoming quite interesting. Specially because this year > we are going to see Vulkan, which is the successor of OpenGL, and > Direct3D 12. Those new graphics API are said to be very low level in > comparison with OpenGL. According to Valve ( > http://www.phoronix.com/scan.php?page=article&item=valve-lunarg-vulkan&num=1 > ), writing a graphics engine for Vulkan is similar to writing a > graphics driver or developing for consoles. All of this requires heavy > support for pointers a la C. Argh. > > Best regards, > Ronie Salgado > > 2015-04-16 18:24 GMT-03:00 Alexandre Bergel <alexandre.bergel(a)me.com > <mailto:alexandre.bergel@me.com>>: > > > 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 > <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>> wrote: > >> > >> No idea, but let us know! > >> > >> Alexandre > >> -- > >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >> Alexandre Bergel http://www.bergel.eu > >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >> > >> > >> > >>> On Apr 16, 2015, at 4:41 AM, Lusa Nicolas <nicolas.lusa(a)usi.ch > <mailto:nicolas.lusa@usi.ch>> 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 > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

April 18, 2015

Re: [Pharo-users] Fwd: Fwd: Debris' Quuve - Technologies used

by stepharo

Just a remark I found strange that not a single little improvements of Magritte was necessary for the Qude project. Now if heavy users of open-source libraries do not enhance these open-source libraries and keep their extensions under close source then the open-source libraries will never make progress and I will immensely sad. You know that I like business and that people can make money but the fight is against other community and competetitor and not within Pharo. Stef Le 17/4/15 19:43, Stephan Eggermont a Ã©crit : > On 16/04/15 16:33, Mariano Martinez Peck wrote: >> 1) We want everything to be ajaxfied (so every single component >> needed to be rewritten for AJAX) > > 2) We want all our components to use Bootstrap layout > > In QCMagritte we managed to keep most, using an Ajax-Memento and > the chained visitors. > >> 3) We want components/descriptions/renderes/etc that better fit our >> own needs >> 4) We needed more hooks > > Definitely. > >> We think Magritte was easy enough >> to extend as is. Another thing we found is that sometimes is a bit >> hard to agree on what is needed for all magritte users. So fully >> refactoring Magritte may affect other developers or other use-cases >> of Magritte. > > Yep, fully agree. > > Stephan > > >

April 18, 2015

Re: [Pharo-users] [ANN] Pharo 4.0 is released!

by volkert

Coooool! Yes, spread the Word. Is there a cool promotion flyer / booklet for Pharo? I found this here: http://files.pharo.org/media/flyer-cheat-sheet.pdf. Not really attractive ... Is there something better? BW, Volkert Am 16.04.2015 um 11:29 schrieb Esteban Lorenzano: > Please spread widely. > Sorry for multiple posts. >

April 18, 2015