- Moose-dev - INF Mailman

by Vincent BLONDEAU

Dear Smalltalk community, My current contract at Lam Research is ending soon, I am looking for job opportunities starting in January 2019. Last year, I finished my Ph.D. in Testing and Software Quality in the Inria's Rmod team in France. I have been working with Pharo for five years and Visual Works for one year. I am also experienced in creating tools to improve the efficiency of the developers. Here are my website: https://vincentblondeau.github.io/ my LinkedIn: https://www.linkedin.com/in/vincent-blondeau/ and my GitHub: https://github.com/VincentBlondeau/ You can find my resume as an attachment. I look forward to hearing from you. Best Regards, Vincent Blondeau

6 years, 8 months

2
1
0 0

Re: [Pharo-users] Pharo eye-candy: Domain-Specific Modeling and Simulation

by Nick Papoylias

Thanx Alex :) Looking forward to the Roassal talk on Thursday ! On Fri, Sep 7, 2018 at 5:22 PM Alexandre Bergel via Pharo-users < pharo-users(a)lists.pharo.org> wrote: > Wow!!!!! > You guys rock! > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > On Sep 6, 2018, at 2:17 PM, Nick Papoylias <npapoylias(a)gmail.com> wrote: > > A nice example of how Pharo can be used for > domain-specific modeling and simulation. Short > session from one of our projects at Rochelle: > > https://www.youtube.com/watch?v=Z7wJNhAIaVQ > > Some additional info here: https://goo.gl/jS4NjB > > Currently investigating how to incorporate the new Bloc based > widgets of @feenkcom into the workflow. > > Cheers, > > Nick > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > > >

6 years, 9 months

1
0
0 0

Pharo eye-candy: Domain-Specific Modeling and Simulation

by Nick Papoylias

A nice example of how Pharo can be used for domain-specific modeling and simulation. Short session from one of our projects at Rochelle: https://www.youtube.com/watch?v=Z7wJNhAIaVQ Some additional info here: https://goo.gl/jS4NjB Currently investigating how to incorporate the new Bloc based widgets of @feenkcom into the workflow. Cheers, Nick

6 years, 9 months

5
8
0 0

Centering edges over composites

by Hernán Morales Durand

Hi, When connecting two composite shapes with RTEdgeBuilder, the connector position loose its center over the connecting shapes. It's easier to explain with two scripts: This one looks good, the connector (RTArrowedLine) is centered: | view shapes myElems | view := RTView new. myElems := 1 to: 2. shapes := (RTSVGPath new path: 'm 3.96875,9.2604167 h 31.75 V 25.135417 C 22.489583,23.8125 17.197917,34.395833 3.96875,27.78125 Z'; fillColor: Color red; borderColor: Color black; borderWidth: 1.2; scale: 1.4) elementsOn: myElems. view addAll: shapes. RTEdgeBuilder new view: view; shape: (RTArrowedLine new color: Color white; yourself); elements: shapes; connectFrom: 1 to: 2. RTTreeLayout new verticalGap: 30; horizontalGap: 30; applyOn: shapes. view inspect. However when adding a label in a composite, both label and arrow looks shifted: | view shape shapes myElems | view := RTView new. myElems := 1 to: 2. shape := RTCompositeShape new add: (RTLabel new text: 'Test'); add: (RTSVGPath new path: 'm 3.96875,9.2604167 h 31.75 V 25.135417 C 22.489583,23.8125 17.197917,34.395833 3.96875,27.78125 Z'; fillColor: Color red; borderColor: Color black; borderWidth: 1.2; scale: 1.4); vertical; yourself. shapes := shape elementsOn: myElems. view addAll: shapes. RTEdgeBuilder new view: view; shape: (RTArrowedLine new color: Color white; yourself); elements: shapes; connectFrom: 1 to: 2. RTTreeLayout new verticalGap: 30; horizontalGap: 30; applyOn: shapes. view inspect. Any idea how to align these shapes? Cheers, Hernán

6 years, 10 months

3
8
0 0

feenk log

by Tudor Girba

Hi, We again got carried away and forgot to update the world about what is up in our corner. Here is a summary: -- Bloc & Brick -- - Text editor stability has been significantly improved - Improved support for selection in the text editor - Support for typical editing keybindings (copy, cut, paste) - Text editor debuggability: https://twitter.com/feenkcom/status/1024680215379959808 https://twitter.com/feenkcom/status/1020768298017992704 - The text editor can handle emojis: https://twitter.com/feenkcom/status/1021872214151507968 -- GT -- - Inspector We now have an initial version of a working inspector with resizable panes: https://twitter.com/feenkcom/status/1030091849795612672 https://twitter.com/feenkcom/status/1030314856736538624 It shows a display string for the current object: https://twitter.com/feenkcom/status/1024564065870512129 It can handle errors in the definition of views gracefully: https://twitter.com/feenkcom/status/1009174937217720320 We now have multiple extensions expressed in the new Inspector: https://twitter.com/feenkcom/status/1024321868566814720 https://twitter.com/feenkcom/status/1022393383850008576 - Documenter saw multiple enhancements. We can now resize various previews live: https://twitter.com/feenkcom/status/1002851190475026432 https://twitter.com/feenkcom/status/1001407762285375490 https://twitter.com/feenkcom/status/1001152789874167808 It now relies on the annotation mechanism from Pillar: https://twitter.com/feenkcom/status/1006508725409079298 We can now link classes and expand their definition: https://twitter.com/feenkcom/status/1014609460520775681 https://twitter.com/feenkcom/status/1029085603948843008 The preview of examples can handle errors gracefully: https://twitter.com/feenkcom/status/1022123808524836864 We can run examples in place, enabling a smoother tutorial experience: https://twitter.com/feenkcom/status/1028390957023223809 We have new documentation expressed in it: https://twitter.com/feenkcom/status/1007008814204444672 Have fun, The feenk team -- www.feenk.com "Presenting is storytelling."

6 years, 10 months

4
4
0 0

Why AnnotationInstance type is container?

by Pavel Krivanek

Hi, In old FAMIX, the FAMIXAnnotationInstance defines two containers: - annotatedEntity - annotationType The annotatedEntity is used for belongsTo, but I would like to know why annotationType was defined as container too. Does it has some reason? Cheers, -- Pavel

6 years, 11 months

3
5
0 0

Moose Java AST?

by Peter Uhnák

Hi, is there a Java AST parser in Pharo? I imagine that jdt2famix must have something inside, but as far as I understand, it just extracts some information from the source code and throws the AST away. Thanks, Peter

6 years, 11 months

4
3
0 0

How to visualize any SVG

by Hernán Morales Durand

Hi, Here I am trying to visualize a SVG figure generic enough to cover many other SVG figures. Currently I use the SVG logo: https://upload.wikimedia.org/wikipedia/commons/0/02/SVG_logo.svg which contains SVG paths, rect, circles and polygons. First I tried to parse with the Athens-SVG included in Pharo 6.1: AthensSceneView new scene: (AthensSVGConverter fromURL: 'https://upload.wikimedia.org/wikipedia/commons/0/02/SVG_logo.svg'); openInWindow but fails with: "Error: cannot resolve url: http://www.w3.org/Graphics/SVG/" So I quickly switched to Roassal SVG. The SVG examples does not cover for example specified colors but they are replaced with Color random. Also using this expression it seems there is no support for "circle" type. RTSVGEntity withAllSubclasses collect: [ : s | s hasSubclasses not ifTrue: [ s new type ] ] as: Set) reject: #isNil with that in mind I tried to parse the SVG logo with the following terrible script which only support paths but can read named or hex colors | tree view | view := RTView new. tree := XMLDOMParser parseURL: 'https://upload.wikimedia.org/wikipedia/commons/0/02/SVG_logo.svg'. view := RTView new. (tree allElementsSelect: [ :e | e isElementNamed: #path ]) elementsDo: [ : node | | elem color colorAtt | color := (node includesAttribute: 'fill') ifTrue: [ Color fromHexString: (((colorAtt := node attributeAt: 'fill') beginsWith: '#') ifTrue: [ colorAtt allButFirst ] ifFalse: [ colorAtt ]) ] ifFalse: [ Color random ]. elem := (RTSVGPath new path: (node attributeAt: 'd'); fillColor: color; scale: 1) element model: (node attributeAt: 'title'). elem @ RTPopup. view add: elem ]. view inspect However adding support for circle, rect, polygon, etc. is becoming too complicated this way :) Is there some other recommended way how to approach this? Cheers, Hernán

6 years, 11 months

1
0
0 0

Roassal2 in Pharo 6.1 (Win) 137 tests fails

by Hernán Morales Durand

In a clean Pharo 6.1 (Windows 8) I loaded Roassal2 with the following spec in a baseline: spec project: 'Roassal2' with: [ spec className: #ConfigurationOfRoassal2; versionString: #stable; repository: 'http://www.smalltalkhub.com/mc/ObjectProfile/Roassal2' ]. But many Trachel tests fails because of "External module not found" error (Screenshots attached). May be Roassal2 is broken on Windows? I tried loading Roassal2 from the Catalog browser and the same 137 tests fails. Any idea what could be missing? Cheers, Hernán

6 years, 12 months

4
7
0 0

[ann] gt documenter

by Tudor Girba

Hi, We are happy to announce a new leap of GToolkit Documenter, the tool for manipulating live documents directly in the development environment: https://github.com/feenkcom/gtoolkit-documenter Documenter is part of the second generation GToolkit project, it is based on Bloc and works with the latest Pillar. It is mainly developed by Juraj Kubelka. Attached you can see a preview of how documents look like: At its core it offers a live editor for manipulating Pillar documents. The interaction happens seamlessly directly in the text editor, and it can be combined with different types of previews to serve several classes of use cases: • code documentation • tutorials • interactive data notebook Code documentation ---- Documenter complements the GToolkit Examples engine to redefine code documentation. When practicing example-driven development, examples get written as part of the typical development. Once examples exist, they can be quickly put together in a document to form documentation. For example, the linked picture shows the comment of a class containing a visual explanation: https://twitter.com/feenkcom/status/973899862482866176 You can see a live example of documentation by inspecting the following snippet: GtDocumenter editorForText: BrToggleExamples comment. Tutorials: ---- Documenter offers a new experience of writing tutorials for Pharo by enabling the creation and embedding of Epicea change sessions directly in the document. For example, take a look at the following animation: https://twitter.com/feenkcom/status/999975333972541440 The document shows a method on top, and a change preview at the bottom showing both the code and the associated diff to the state from the image. Applying the change updates both the change view (no more diff), and method preview. This speeds up significantly the process of going through a tutorial. Furthermore, given that now the document shows the diff to the current image, the reader can safely explore alternative scenario and come back to the tutorial at any time without losing the overview. The size of the preview can also be adjusted live: https://twitter.com/feenkcom/status/1001152789874167808 https://twitter.com/feenkcom/status/1001407762285375490 You can see a live tutorial by inspecting: IceRepository repositoriesLocation / 'feenkcom'/ 'gtoolkit-examples' / 'doc' / 'tutorial' / 'examples-tutorial.pillar’. Interactive data notebook: ---- A Documenter document can also be used as an interactive notebook. Internally it essentially acts as a playground: • it supports defining variables in code snippets, and • the execution of code shows an embedded inspector. For example: https://twitter.com/feenkcom/status/996310432225820672 https://twitter.com/feenkcom/status/1002851190475026432 An example, can be seen by inspecting: IceRepository repositoriesLocation / 'feenkcom'/ 'gtoolkit' / 'doc' / 'gtoolkit' / 'gtoolkit.pillar'. As always, please do let us know what you think. Enjoy, The feenk team -- www.tudorgirba.com www.feenk.com "If you can't say why something is relevant, it probably isn't."

7 years

4
5
0 0

Beginner questions re. Moose analysis of C++ source code

by smallglt

I'm totally new to Moose (and effectively new to Smalltalk) and need a pointer or two on analyzing an old application that was developed in Visual C++ 2006. I have the complete sources, including the Visual Studio project files, resource files, etc. I've already got Pharo and Moose installed on my Windows system and have been able to get the Moose playground to run, but that's about it. So far I don't know how to get Moose to do anything else. My initial goal is just to get this source code "loaded" into Moose. I've seen references to VerveineC-Cpp and Famix-C but no explanation of how to use either one. I haven't had an opportunity yet to try VerveineC-Cpp on Windows 10 at my office. On my personal Mac (i.e. not on the office system where I actually need to do this work) I installed Eclipse Oxygen and tried to follow the very limited directions to install VerveineC-Cpp, but Eclipse complains about the build path. Maybe Eclipse Mars is needed instead of Jupiter? It also looks like I might need to use the old, deprecated Java V1.7 for MacOS, instead of a current version of Java? (Hopefully I won't need an older version of MacOS. I'm running Sierra V10.12 with all updates as of this writing.) Maybe that would all be more straightforward somehow on Windows? (I also have Linux at work, if that would be any easier.) As for Famix-C, I see that it appears to be "built in" to the Moose environment that I installed at work and at home. But I don't know how to make it do anything. I greatly appreciate any hints or suggestions. I'm very eager to begin using Moose and to (re)learn Smalltalk, especially in the Pharo environment which looks really fascinating. (Trivia: Back in the early 1990's or thereabouts, while taking a graduate course in operating system design, I learned enough Smalltalk to get me started on writing an emulator for the simple machine specification the professor gave us. But a single academic quarter, roughly three months, just wasn't enough time to both learn a totally new, object oriented programming paradigm /and/ use it to complete such a program, while also holding down a full time job and leading a regular life. :-) But I did write a good paper explaining my ideas and how far I'd actually been able to carry them. The professor was understanding, liked my concept, and I managed to get a B+ grade for the course.) -- Sent from: http://forum.world.st/Moose-f1310756.html

7 years

6
10
0 0

[ANN] PolyMath release 0.101

by Serge Stinckwich

We are pleased to announce the release of PolyMath 0.101 PolyMath is a numerical computing and data analysis library on top of Pharo. The code is available here: https://github.com/PolyMathOrg/PolyMath and can be loaded in a fresh Pharo 6.1 image with: Metacello new repository: 'http://smalltalkhub.com/mc/PolyMath/PolyMath/main'; configuration: 'PolyMath'; version: '0.101'; load The current work is mostly focused on cleaning the codebase in order to release the 1.0 version for September 2018. Please help us, by looking at the issues here: https://github.com/PolyMathOrg/PolyMath/issues , joining #polymath channel on Discord or polymath mailing-list: https://groups.google.com/forum/#!forum/polymath-project -- Serge Stinckwich UMI UMMISCO 209 (SU/IRD/UY1) "Programs must be written for people to read, and only incidentally for machines to execute."http://www.doesnotunderstand.org/

7 years

3
7
0 0

feenk log

by Tudor Girba

Hi, We were a bit silent the last couple of months. Quite a bit happened in the meantime, so here is a summary (for more fine grained announcements, you can follow us on Twitter): ---- Bloc ---- - Scrolling. We finally have a good scrolling support: https://twitter.com/feenkcom/status/991690465224331264 This might sound like a trivial feature, but it turns out it is not. We had a bug that forced us to rethink the support quite deeply in order to be able to debug it. To do this, we now can simulate time in Bloc, which is really cool: https://twitter.com/feenkcom/status/989797367523233797 https://twitter.com/feenkcom/status/988753142299938817 (as a side note, the bug we fought with was the last - Pannable element is a combination of a scrollable element with a scalable element, and it offers the possibility either to zoom in/out + scroll, or to fit screen and resize when the parent resizes. - PDF, SVG, PNG, JPG export (based on the underlying Moz2D support): https://twitter.com/feenkcom/status/976580153802358786 https://twitter.com/feenkcom/status/976578060429484032 - Better curve support: https://twitter.com/feenkcom/status/990967109193781249 https://twitter.com/feenkcom/status/990971530615107584 - Better debugging support for understanding bounds: https://twitter.com/feenkcom/status/989138457288167424 ---- Brick ---- - We now have simple list and columned list widgets. The list is both fast and scalable and supports rows of variable heights: https://twitter.com/feenkcom/status/984744251920658432 https://twitter.com/feenkcom/status/984143821192744961 - Basic tab widget: https://twitter.com/feenkcom/status/974420432240685062 - Looks: a mechanism for specifying element-specific composition and interaction. ---- GT ---- - Documenter saw some major improvements. Just a reminder, Documenter is the tool that enables live programming and previews directly within Pillar documents. We now have a capability similar to notebooks like Jupyter: https://twitter.com/feenkcom/status/996310432225820672 We use it extensively to document our code. For example, here is a tutorial about playing with looks in Bloc: https://twitter.com/feenkcom/status/973899862482866176 And we can also express whole tutorials based on Epicea: https://twitter.com/feenkcom/status/999975333972541440 - Diagrammer. We now have better editing support for detailed things such as arrow head: https://twitter.com/feenkcom/status/976341449267531776 While Diagrammer is apparently a tool for diagrams, it has a rather generic design that can be utilized for all sorts of use cases. For example, one side effect is that now all elements can be visually edited: https://twitter.com/feenkcom/status/982656456968241152 - Mondrian: Using the new pannable element, we can now zoom in/out and scroll, and we can also set element to fit screen. We can also drag elements around. - Inspector: we now have an initial support for multiple views associated with an object. The support is similar to the one from the current inspector. Have fun, The feenk team -- www.tudorgirba.com www.feenk.com "What is more important: To be happy, or to make happy?"

7 years, 1 month

4
8
0 0

CFP - IWST 2018 - International Workshop on Smalltalk Technologies

by Anne Etien

Hi Smalltalkers, Just a kind reminder, deadline is in two weeks. We are waiting for your submission! Loic and Anne CFP - IWST 2018 - International Workshop on Smalltalk Technologies [Please accept our apologies if you receive multiple copies of this call] [Please send to interested colleagues / mailing-lists] ************************************************************************************************************ CALL FOR PAPERS IWST 2018 — International Workshop on Smalltalk Technologies http://esug.org/wiki/pier/Conferences/2018/International-Workshop-IWST_18 <http://www.esug.org/wiki/pier/Conferences/2017/International-Workshop-IWST_…> Cagliari, Italy; Between September 10th and 14th, 2018 ************************************************************************************************************ ------------------- Goals and scopes ------------------- The goals of the workshop is to create a forum around advances or experience in Smalltalk and to trigger discussions and exchanges of ideas. The topics of your paper can be on all aspect of Smalltalk, theoretical as well as practical. Participants are invited to submit research articles or industrial papers. This year we want to open two different tracks: one research track and one industrial track with less scientific constraints. We expect papers of three kinds: Short position papers describing emerging ideas Long research papers with deeper description of experiments and of research results. Industrial papers with presentation of real and innovative Smalltalk applications; this kind of paper should enlighten why Smalltalk is really appropriate for your application. We will not enforce any length restriction. -------------------- Important Dates -------------------- Submission deadline: June 15th, 2018 Notification deadline: July 10th, 2018 Workshop : between September 10th and 14th, 2018 All accepted papers will be published in ACM DL (To be confirmed) ------------------- Topics ------------------- We welcome contributions on all aspects, theoretical as well as practical, of Smalltalk related topics such as: -Aspect-oriented programming, -Design patterns, -Experience reports, -Frameworks, -Implementation, new dialects or languages implemented in Smalltalk, -Interaction with other languages, -Meta-programming and Meta-modeling, -Tools ------------------- Best Paper Award ------------------- To encourage the submission of high-quality papers, the IWST organizing committee is very proud to announce a Best Paper Award for this edition of IWST. We thank the Lam Research Corporation for its financial contribution which makes it possible for prizes for the three best papers: 1000 USD for first place, 600 USD for second place and 400 USD for third place. The ranking will be decided by the program committee during the review process. The awards will be given during the ESUG conference social event. The Best Paper Award will take place only with a minimum of six submissions. Notice also that to be illegible, a paper must be presented at the workshop by one of the author and that the presenting author must be registered at the ESUG conference. ------------------- Publication ------------------- Both submissions and final papers must be prepared using the ACM SIGPLAN 10 point format. Templates for Word and LaTeX are available at http://www.acm.org/sigs/sigplan/authorInformation.htm <http://www.acm.org/sigs/sigplan/authorInformation.htm>. This site also contains links to useful informations on how to write effective submissions. ------------------- Submission ------------------- All submissions must be sent via easychair: https://easychair.org/conferences/?conf=iwst18 <https://easychair.org/conferences/?conf=iwst18> ------------------- Program chairs ------------------- Anne Etien (Université de Lille, France) Loic Lagadec (Ensta Bretagne, France)

7 years, 1 month

1
0
0 0

Is anyone using C/C++ models

by Pavel Krivanek

Hi, the old Famix implementation has some irregularly defined relations in parts related to C/C++ meta-metamodels and we should not move them this way to the compatibility metamodel defined in new Famix. So I would like to ask, is anyone of you using C/C++ models in practice now? If not, we do not need to bother with the keeping of the backward compatibility for every price. Thank you -- Pavel

7 years, 1 month

2
1
0 0

roslyn2famix - C# importer

by Tudor Girba

Hi, We are happy to announce roslyn2famix, a C# importer. It is based on Roslyn, and was mainly developed by George Ganea. It is released under Apache 2.0, the same license as Roslyn: https://github.com/feenkcom/roslyn2famix The importer has a structure similar to the one of jdt2famix, including a Fame implementation in C#, and FAMIX code generated out of the Moose code. We also have a few CSharp specific entities that are already present in Moose-CSharp. The importer takes as input a C# solution (.sln), and produces an MSE file that can be loaded in the latest Moose. Cheers, The feenk team -- www.tudorgirba.com www.feenk.com "Be rather willing to give than demanding to get."

7 years, 1 month

4
5
0 0

C# importer ?

by Johan Fabry

Hi all, And now it looks like I will need to analyze a part of our own code, written in C#. Is there a parser for C# in Moose and if so, how extensive/solid is it? TIA -- Johan Fabry, Senior Software Engineer. johan(a)raincode.com | Email too brief? Here's why! http://emailcharter.org

7 years, 1 month

7
12
0 0

Column width in characters?

by Luke Gorrie

I would like to make my GTInspector views work well with different font sizes. In particular, some people find the default Pharo font too small and want to switch to a larger one. The main problem is that my tables have their column width specified in pixels. The values are chosen to make good use of screen space with the default font size, but it becomes unreadable with a larger font that doesn't fit. How should I solve this? The first idea that comes to mind is to invent my own units that are scaled according to system font size when converted to pixels. I wonder if there is a better known solution already though. Cheers! -Luke

7 years, 1 month

2
1
0 0

Re: [ann] gt diagrammer

by Tudor Girba

Hi, > On Apr 18, 2018, at 9:54 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Hi Doru, > > Le 18/04/2018 à 06:45, Tudor Girba a écrit : >> Hi, >> Sorry for the late reply. I missed this email. >> BlInfiniteElement’s comment says: >> "I'm an element which is supposed to contain huge amount of children and layout only those of them that are visible inside my viewport. >> I work with DataSources to fetch data from and can present data within different Infinite Layouts.” > > Ok so this is a generalisation of the fasttable approach. > > I wanted to know if it could handle data sources where elements size is variable and unknown unless you render the element. Yes, it does: https://twitter.com/feenkcom/status/984744251920658432 >> It is used in both lists and in the text editor. > > Obvious, isn't it. A text is a list of lines... > >> I am not sure which variable you refer to by "currently processing a request”. Can you clarify? > > Can't find it, but must have been triggered when looking at variables like layoutRequestEaten. Yes, it seems like it. > > Interesting: found the cache used in the BLInfiniteElement (BlRecycler?). Also found a pool (BlInfinitePool) ? Couldn't find what it could be a pool of... Strange, you add things in the pool when you release them (so you fill the pool by releasing objects?). Looks like a LIFO stack to me. I am not quite sure what you mean by filling the pool by releasing objects. Can you explain? Also, I let Alex describe the details :) Doru > Regards, > > Thierry > >> Cheers, >> Doru >>> On Apr 9, 2018, at 3:54 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: >>> >>> The only way one can review it is to reverse engineer the whole code >>> base then. How much did you say? 2 peoples, how many months? >>> >>> A few questions then, after a cursory glance: >>> >>> - In what way an infinite BlElement is infinite? >>> - Why does an infinite BlElement has what seems to be a sort of >>> "currently processing a request" instance variable? >>> >>> Regards, >>> >>> Thierry >>> >>> 2018-04-09 14:08 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >>>> Hi, >>>> >>>> We are doing that. We rewrote the system multiple times precisely because of these reasons. We could certainly do better, but I think that any meaningful conversation must happen around code, and we’d be happy to learn where we did not exploit all abstractions we could. Actually, I would be happy to even have a conversation about issues, even if the solution is not given. It can start by simply being pointed to code that does not sound right. >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>>> On Apr 9, 2018, at 1:04 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: >>>>> >>>>> 2018-04-09 12:00 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >>>>>> >>>>>> >>>>>>> On 9 Apr 2018, at 11:36, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2018-04-09 11:23 GMT+02:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: >>>>>>> Hi, >>>>>>> >>>>>>> For the record, View class, a root class of all visual elements in Android 27 is 26'488 lines of code. It didn't hover prevent it from being used on more than 2 billion devices :) >>>>>>> >>>>>>> Remind me, please: what is the budget of Google for the ongoing maintenance of Android? >>>>>>> >>>>>>> The core of Bloc is just 14k lines of code. It would be nice to know how many lines of code should be considered too much, 5k, 7.43k or 10k. >>>>>>> >>>>>>> For a non-rendering core? 2k. >>>>>> >>>>>> I think that having a time/space efficient high quality well documented code base is definitively a goal, they are probably not there yet. >>>>>> >>>>>> Being the smallest out there is probably not a goal, nor is that a particularly interesting one, IMHO. >>>>> >>>>> Small means a real effort has been to: >>>>> >>>>> - not reimplement already available mechanisms, >>>>> >>>>> - build the most effective abstractions, >>>>> >>>>> - do not factor in unneeded customizations points, >>>>> >>>>> I value highly someone that try to reach thoses. >>>>> >>>>> Thierry >>>>> >>>>>>> Thierry >>>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> Alex >>>>>>> >>>>>>> On 9 April 2018 at 11:12, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: >>>>>>> >>>>>>> >>>>>>> 2018-04-09 11:02 GMT+02:00 Serge Stinckwich <serge.stinckwich(a)gmail.com>: >>>>>>> >>>>>>> >>>>>>> On Mon, Apr 9, 2018 at 9:54 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: >>>>>>> 2018-04-09 9:14 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I think it might be more interesting to start the review from the usage of it, not from the internals. >>>>>>> >>>>>>> Well, from the usage of it, I've seen nothing that doesn't fit into >>>>>>> the yagt. I've seen that field evolve and try clever things, really >>>>>>> different things, and Bloc does not look like one of thoses. >>>>>>> >>>>>>>> Indeed, Bloc is primarily an engineering effort. But, there are a couple of things that make it rather different from other solutions. For example: >>>>>>>> - Only one rendering tree in all cases. This works also for graph visualizations that work with any element without imposing knowledge about edges in the base system. We think this is quite important, and especially when combined with a performant rendering, it can open new doors for UI design. >>>>>>> >>>>>>> Look, from the point of view of the man of the art, it doesn't seems >>>>>>> like a breakthrough. >>>>>>> >>>>>>> >>>>>>> Do we need a breakthrought for UI ? >>>>>>> No ! >>>>>>> We need something that works that's it, stable software with good documentation and tests. >>>>>>> After that people can build the next-UI if they want, but this is build on solid foundations. >>>>>>> >>>>>>> Agreed. And this is where it is critical. >>>>>>> >>>>>>> I used Morphic since Self 3.0, beginning of my PhD (1994, I think), followed it to the beginning of Squeak (1998). When I came back to Pharo in 2011, I was horrified by what it has became: a monster of thousands over thousands of buggy lines. >>>>>>> >>>>>>> And now I see a replacement, that, before going into production, is already at 45k lines? And with a planned, huge dependency on the GUI lib of another project? >>>>>>> >>>>>>> Do you imagine how it will be, 10 years down the line? >>>>>>> >>>>>>> Do you think it will be the stable foundation you're looking for? >>>>>>> >>>>>>> >>>>>>> >>>>>>> Compared to other smalltalk-based solutions, yes, it may be seen as an >>>>>>> improvement. >>>>>>> >>>>>>> I think you underestimate how advanced that field has been / is, and >>>>>>> how far behind the state of the art are industrial solutions. >>>>>>> >>>>>>> There is only one development in the Smalltalk space in GUI that is >>>>>>> worthy of interest for me: the anti-aliasing of Juan Vuletich. It >>>>>>> would have so much impact overall (remove all dependencies on external >>>>>>> libs, remove the need to do font anti-aliasing, scrap thousands of >>>>>>> lines of slow and ugly Smalltalk code, simplify the FreeType >>>>>>> infrastructure, remove MBs of external librairies, ensure long-term >>>>>>> porting ease / code evolution). >>>>>>> >>>>>>> M >>>>>>> aybe this was a breakthrought, but how many users ? >>>>>>> >>>>>>> Very few users. Juan has not yet implemented it. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Thierry >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> -- >>>>>>> Serge Stinckwich >>>>>>> UMI UMMISCO 209 (SU/IRD/UY1) >>>>>>> "Programs must be written for people to read, and only incidentally for machines to execute." >>>>>>> http://www.doesnotunderstand.org/ >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Moose-dev mailing list >>>>>>> Moose-dev(a)list.inf.unibe.ch >>>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Moose-dev mailing list >>>>>>> Moose-dev(a)list.inf.unibe.ch >>>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Moose-dev mailing list >>>>>>> Moose-dev(a)list.inf.unibe.ch >>>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Moose-dev mailing list >>>>>>> Moose-dev(a)list.inf.unibe.ch >>>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev(a)list.inf.unibe.ch >>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev(a)list.inf.unibe.ch >>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>>> >>>> -- >>>> www.tudorgirba.com >>>> www.feenk.com >>>> >>>> "We cannot reach the flow of things unless we let go." >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev(a)list.inf.unibe.ch >>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)list.inf.unibe.ch >>> https://www.list.inf.unibe.ch/listinfo/moose-dev >> -- >> www.tudorgirba.com >> www.feenk.com >> "Things happen when they happen, >> not when you talk about them happening." >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev -- www.tudorgirba.com www.feenk.com "Don't give to get. Just give."

7 years, 2 months

3
3
0 0

[ann] gt diagrammer

by Tudor Girba

Hi, We are happy to announce an initial version of GT Diagrammer, an engine for constructing diagrams interactively. This is the newest addition to the next generation GT built on Bloc. It looks like this: https://twitter.com/feenkcom/status/976341449267531776 We chose to work on Diagrammer for multiple reasons. First, developers often need to create hand built diagrams to communicate intentions, and an integrated experience should not require us to leave our environment to create them. At the same time, Diagrammer is an application that requires a widgets and interactions, and thus it is a nice exercise for Bloc and Brick. One requirement we had from the beginning was to make it work with any Bloc element. This means that the editing part had to be reasonably generic. To this end, we now have elements that can define visual editors. This is somewhat a combination between Magritte descriptions, and inspector extensions. An interesting side effect is that now we can edit visual properties when inspecting any element. In other words, we got the basic infrastructure of a UI painter. It looks like this: https://twitter.com/feenkcom/status/982656456968241152 The user interface essentially relies on two widgets: scrollable list and toggle button. While the visual look of the toggle button is inspired from material design, the most interesting part is that now we have an implementation for controlling looks per element instance. A key issue here is that looks can react to events coming from the element and inject visual attributes and possible even change behavior (for example, changing an icon while pressing a button). We will post more about looks soon. We now also have a nice solution for overlays. For example, we have an overlay showing selection and an overlay for resizing elements. Perhaps less obvious, Diagrammer also offers a basic infrastructure for the area of visual languages. As Diagrammer works with any Bloc elements, we can simply create dedicated visual elements. As an example, Diagrammer comes with an implementation of a UML class figure. Furthermore, as the functionality does not impose a specific model, custom language semantics can be mapped on visual actions. There are several things to do still for it to become a mature solution. An important next step is to serialize a diagram scene in a reproducible manner. Currently, the diagram (or any element) can be exported as pdf (https://twitter.com/feenkcom/status/976580153802358786), svg (https://twitter.com/feenkcom/status/976578060429484032), png, gif or jpeg by directly using the low level canvas. However, for the diagram to be truly useful we need to store the result in either code or another reloadable form such as STON. Other future directions are related to figure controlling (for example, custom anchors or line bending points) and to enhanced editors. To play with it, the easiest way is to download the new GT in a Pharo 6.1 image: Metacello new baseline: 'GToolkit'; repository: 'github://feenkcom/gtoolkit/src'; load. And then inspect: GtDiagrammerElement new Cheers, The feenk team -- www.tudorgirba.com www.feenk.com "Presenting is storytelling."

7 years, 2 months

9
29
0 0

C/Cpp parser

by Nicolas Anquetil

Synectique is openning the source code for a C/C++ parser based on Eclipse CDT. https://github.com/Synectique/VerveineC-Cpp.git The parser was developed as an Eclipse (Mars release) plugin and is under MIT licence. nicolas -- Nicolas Anquetil -- MCF (HDR) Project-Team RMod

7 years, 2 months

3
2
0 0

PetitParser2 is not loading from catalog in Pharo6.1

by Stéphane Ducasse

Hi guys Giovanni is in my office and telling that (and we verified it) that PetitParser2 cannot load from the catalog in Pharo 6.1 Stef -------------------------------------------- Stéphane Ducasse http://stephane.ducasse.free.fr http://www.synectique.eu / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, Bât.A, Park Plaza Villeneuve d'Ascq 59650 France

7 years, 2 months

2
6
0 0

How to get a GLMRubricTextPresentation with StandardFonts codeFont ?

by Johan Fabry

Hi all, I posted a question like this a week ago but had no response, so here we go, more explicitly: I would like a get a GLMRubricTextPresentation using the StandardFonts codeFont. I do not see how to configure this. The text is not ST so I cannot use the different ST presentations that are available. I have been looking for some time now, but cannot see a solution. Can anybody help me out? -- Johan Fabry, Senior Software Engineer. johan(a)raincode.com | Email too brief? Here's why! http://emailcharter.org

7 years, 2 months

3
3
0 0

Some simple questions

by Jannik Laval

Hello, I am defining my own metamodel, and I am using the MSE pragmas. I use <MSEProperty:type:opposite:> and <multivalued> I also see the pragma <derived>. Could you explain me what it is? And also, for example, in FAMIXReference>>target, there is a pragma <target> (same for <source>). Is it a specific pragma ? Is there a page explaining all the available pragmas ? Thanks a lot for your help Best regards, -- ~~Jannik Laval~~ Enseignant-chercheur http://www.jannik-laval.eu http://www.phratch.com http://www.approchealpes.info

7 years, 2 months

2
2
0 0

roassal question

by Nicolas Anquetil

This is one that I already had several times and could not find a proper answer: How to have nodes grouped in containers (e.g. classes in packages) and links from one inner node (i.e. a class) to another one possibly from a different container (e.g. inheritance links from one package to another one) ? nicolas -- Nicolas Anquetil RMod team -- Inria Lille

7 years, 2 months

3
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev