- Pharo-dev - lists.pharo.org

[Pharo 9.0] Build #309: CleanupOCKeyedSet2

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #309 was: FAILURE. The Pull Request #6371 was integrated: "CleanupOCKeyedSet2" Pull request url: https://github.com/pharo-project/pharo/pull/6371 Issue Url: https://github.com/pharo-project/pharo/issues/CleanupOCKeyedSet2 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 25, 2020

[CfP] MPLR 2020 - 17th International Conference on Managed Programming Languages & Runtimes

by Stefan Marr

======================================================================== Call for Papers MPLR 2020 - 17th International Conference on Managed Programming Languages & Runtimes November 4-6, 2020 in Manchester, United Kingdom https://mplr2020.cs.manchester.ac.uk/ Follow us @MPLR_Conf ======================================================================== The 17th International Conference on Managed Programming Languages & Runtimes (MPLR, formerly ManLang) is a premier forum for presenting and discussing novel results in all aspects of managed programming languages and runtime systems, which serve as building blocks for some of the most important computing systems in use, ranging from small-scale (embedded and real-time systems) to large-scale (cloud-computing and big-data platforms) and anything in between (desktop, mobile, IoT, and wearable applications). This year, MPLR will be held in Manchester, UK, as permitted considering Health and safety concerns. For up-to-date details, check out the conference website: https://mplr2020.cs.manchester.ac.uk/ and follow us on Twitter @MPLR_Conf. The areas of interest include but are not limited to: * Languages and Compilers - Managed languages (e.g., Java, Scala, JavaScript, Python, Ruby, C#, F#, Clojure, Groovy, Kotlin, R, Smalltalk, Racket, Rust, Go, etc.) - Domain-specific languages - Language design - Compilers and interpreters - Type systems and program logics - Language interoperability - Parallelism, distribution, and concurrency * Virtual Machines - Managed runtime systems (e.g., JVM, Android Runtime (ART), V8, LLVM, .NET CLR, RPython, GraalVM, etc.) - VM design and optimization - VMs for mobile and embedded devices - VMs for real-time applications - Memory management and garbage collection - Hardware/software co-design * Techniques, Tools, and Applications - Static and dynamic program analysis - Testing and debugging - Refactoring - Program understanding - Program synthesis - Security and privacy - Performance analysis and monitoring - Compiler and program verification Submission Categories --------------------- MPLR accepts four types of submissions: 1. Regular research papers describing novel contributions involving managed language platforms. Research papers will be evaluated based on their relevance, novelty, technical rigor, and contribution to the state-of-the-art. Format: up to 12 pages, excluding bibliography and appendix 2. Work-in-progress research papers describing promising new ideas, with perhaps less maturity than full Papers. Work-in-progress papers will be evaluated with an emphasis on novelty and the potential of the new ideas instead of technical rigor and experimental results. Format: up to 6 pages, excluding bibliography and appendix 3. Industry and tool papers presenting technical challenges and solutions for managed language platforms in the context of deployed applications and systems. Industry and tool papers will be evaluated on their relevance, usefulness, and results. Suitability for demonstration and availability will also be considered for tool papers. Format: up to 6 pages, excluding bibliography and appendix 4. Posters They will be evaluated similarly to work-in-progress papers. Posters can accompany any submission as a way to provide additional demonstration and discussion opportunities. Format: poster and 1-page abstract MPLR 2020 submissions must conform to the ACM Policy on Prior Publication and Simultaneous Submissions and to the SIGPLAN Republication Policy. See http://www.sigplan.org/Resources/Policies/Republication/ Author Instructions ------------------- Submissions need to use the ACM `acmart` format with the `sigconf` style: https://www.acm.org/publications/proceedings-template If you are using LaTeX, submissions need to use the 'acmart' document class with the 'sigconf' option. For reviewing, please include page numbers in your submission using the LaTeX command `\settopmatter{printfolios=true}`. The standard settings of a 9 point font size and the Libertine/Biolinum font family are to be kept. All submissions need to be in PDF format. MPLR uses single-blind reviewing, i.e., author names are generally included in submissions. Please also ensure that your submission is legible when printed on a black and white printer. In particular, please check that colors remain distinct and font sizes are legible. Submission Site: https://mplr2020.cs.manchester.ac.uk/submissions/ Important Dates --------------- Submission Deadline: 12 August 2020 Author Notification: 14 September 2020 Camera Ready: 05 October 2020 Conference Dates: 04-06 November 2020 All deadlines are 23:59 AoE (UTC-12h). AUTHORS TAKE NOTE: The official publication date is the date the proceedings are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of your conference. The official publication date affects the deadline for any patent filings related to published work. COVID-19 -------- Given the uncertainties of the current situation, we want to assure you that MPRL is going to happen. To increase the likelihood of having a physical conference, we are planning it for November. If this wonât be possible, we are preparing a virtual MPLR, learning from the conferences taking place right now and over the summer. In either case, the submission and reviewing process will happen as outlined to ensure timely feedback and continuity for our research work. Organization ------------ Program Committee: Jeronimo Castrillon, TU Dresden, Germany Shigeru Chiba, University of Tokyo, Japan Irene Finocchi, LUISS Guido Carli University, Italy Juliana Franco, Microsoft Research, UK Elisa Gonzalez Boix, Vrije Universiteit Brussel, Belgium Robert Hirschfeld, Hasso Plattner Institute, Germany Roberto Ierusalimschy, PUC-Rio, Brazil Georgia Kouveli, ARM, UK Burcu KÃ¼lahÃ§Ä±oÄlu Ãzkan, MPI-SWS, Germany Doug Lea, SUNY Oswego, USA Daryl Maier, IBM, Canada Mark Marron, Microsoft Research, USA Hidehiko Masuhara, Tokyo Institute of Technology, Japan Hanspeter MÃ¶ssenbÃ¶ck, JKU Linz, Austria Hannes Payer, Google, Germany Julien Ponge, Red Hat, France Aleksandar Prokopec, Oracle Labs, Switzerland Manuel Rigger, ETH Zurich, Switzerland Andrea Rosa, USI, Switzerland Jeremy Singer, University of Glasgow, UK Eli Tilevich, Virginia Tech, USA Sam Tobin-Hochstadt, Indiana University, USA Tobias Wrigstad, Uppsala University, Sweden General Chair: Christos Kotselidis, University of Manchester, UK Program Chair: Stefan Marr, University of Kent, UK If you are unsure whether a particular topic falls within the scope of MPRLâ20 or if you have any other questions, please do not hesitate to contact the Program Chair (s.marr(a)kent.ac.uk) -- Stefan Marr School of Computing, University of Kent https://stefan-marr.de/research/

May 25, 2020

Re: [Pharo-dev] uFFI: What is the difference between FFIExternalObject and FFIOpaqueObject?

by Esteban Lorenzano

Hi, Thatâs not really possible :) In your case, Method is already a pointer (with arity 1). Which means Method * Is in fact a pointer to a pointer (arity 2), something like "void**" This is a typical case, but you are not âhaving the two casesâ, you still have one :) UFFI will try to box/unbox that for you, btwâ¦ but sometimes this is not what you want (because pointers to pointers is a typical way to answer lists, for example). And UFFI does not know what you want thereâ¦ in this cases (when you want the list), the recommended way is to get the pointer and create the list yourself. Instead: Method *methodList() You call void *methodList() To avoid the unbox attempt, and then you process your answer âin rawâ (for example using the #readArrayOf:until: method). If it happens that you use both SomeStructure, and SomeStructure*, then is not an opaque type, and you need to map it by subclasses FFIExternalStructure and implementing fieldsDesc, etc. Esteban > On 23 May 2020, at 20:00, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Esteban Lorenzano wrote >> The easiest way I have to explain is: >> >> You use an OpaqueObject when you will refer to the opaque type in calls >> as: someFunction(opaqueobject *someArg). >> You use an ExternalObject when you will refer to the opaque type in calls >> as: someFunction(externalobject someArg). > > Very clear! We're getting somewhere :) But... > > What if a type is used both ways? > > For example: > ^ self ffiCall: #(Method * class_copyMethodList(Class self, uint > *outCount)) > and > ^ self ffiCall: #(struct objc_method_description * > method_getDescription(Method self)) > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

May 24, 2020

Re: [Pharo-dev] uFFI: What is the difference between FFIExternalObject and FFIOpaqueObject?

by Ben Coman

On Sun, 24 May 2020 at 02:01, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Esteban Lorenzano wrote > > The easiest way I have to explain is: > > > > You use an OpaqueObject when you will refer to the opaque type in calls > > as: someFunction(opaqueobject *someArg). > > You use an ExternalObject when you will refer to the opaque type in calls > > as: someFunction(externalobject someArg). > > Very clear! We're getting somewhere :) But... > > What if a type is used both ways? > > For example: > ^ self ffiCall: #(Method * class_copyMethodList(Class self, uint > *outCount)) > and > ^ self ffiCall: #(struct objc_method_description * > method_getDescription(Method self)) > In advance of Esteban's answer I'd like to understand better your situation above. Passing a method to a function seems like setting up a call-back? Do you have a concrete C example that can be viewed in its full context? cheers -ben

May 24, 2020

Re: [Pharo-dev] Project of Interest => Jekyll + Dynamic processing integration + Git(hubs)Pages => pharo in the middle

by Esteban Maringolo

On Sat, May 23, 2020 at 5:41 PM CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: > Hi Esteban, >> This comes really on time for me, I decided to rewrite to small sites I have using Jekyll, and as read all their tutorials I thought even of having a Jekyllst variation, that uses the Jekyll directories and other conventions, but uses Smalltalk as its engine. Of course this is far reached given my real availability these days, that's lower than usual. > Cool anyway if thatâs something that interest you too. What do you think of https://gohugo.io ? > Themes are pretty cool https://themes.gohugo.io I wasn't aware of this, looks great, albeit on a different tool stack. The generated output is "sane" html (read below). > However I'd like to be part of conversations around this, and eventually contribute to it, because I already started playing with Jekyll (and Gatsby as well). > Perfect :) > This is not urgent but I need to put 2 websites online for September (simple ones). For now, Iâm trying around. Summer will be perfect for me to work on such project. I have a small pet site, that has some particular features like being multilingual and having some "dynamic" data source. I decided to give a try to Gatsby this evening, and found it to be great and produce uber fast rendered pages, but the produced HTML/CSS/JS is worst than reading assembly language. However since what I wanted was to improve the speed and some limitations of an old Wordpress based site, I think I'll stick with it. It also refreshes my React.js shenanigans. Regards! Esteban A. Maringolo

May 23, 2020

Re: [Pharo-dev] Project of Interest => Jekyll + Dynamic processing integration + Git(hubs)Pages => pharo in the middle

by CÃ©drick BÃ©ler

Hi Esteban, > This comes really on time for me, I decided to rewrite to small sites I have using Jekyll, and as read all their tutorials I thought even of having a Jekyllst variation, that uses the Jekyll directories and other conventions, but uses Smalltalk as its engine. Of course this is far reached given my real availability these days, that's lower than usual. Cool anyway if thatâs something that interest you too. What do you think of https://gohugo.io <https://gohugo.io/> ? Themes are pretty cool https://themes.gohugo.io <https://themes.gohugo.io/> > > However I'd like to be part of conversations around this, and eventually contribute to it, because I already started playing with Jekyll (and Gatsby as well). Perfect :) This is not urgent but I need to put 2 websites online for September (simple ones). For now, Iâm trying around. Summer will be perfect for me to work on such project. Cheers, CÃ©drick > > Regards, > > > Esteban A. Maringolo > > > On Sat, May 23, 2020 at 10:15 AM CÃ©drick BÃ©ler <cdrick65(a)gmail.com <mailto:cdrick65@gmail.com>> wrote: > Hi there, > > This post is just to talk about one side project Iâm exploring and interested in from a long time. I think it may interest other people here. > > Iâd like to have powerful (static based) web site so hosting is really cheap (even free) and hassle free. Iâve my own server for years, it is cheap and simple but, of course, it needs some maintenance (linux update, nginx scripts, â¦) even if tools are the simplest Iâve found. > > Recently thanks to student projects ;-), I found some time to learn what I find is a wonderful solution. This solution is to use GitHub DSCM, GitHub Pages and Jekyll (a ruby static site generator that is natively integrated) all together. > https://jekyllrb.com <https://jekyllrb.com/> > > The beauty is that you can edit the site straight on GitHub. We get the power of version system and hosting for freeâ¦ > It literally is a CMS and the cheapest and reliable that I know of (grav might be another option). > > Of course, there are some Â« dynamic Â» content possibilities too (otherwise GitHub Pages is enough) > - blog posts are natively generated through new files according to a name convention. > - there are plugins too (but you have to watch for compatibility in GitHub). > > Dealing with forms and comments is possible > - solutions that are hosted on a third-party. Solution like Discus or formspree, â¦ (thatâs a NO GO to me) > - web service integration that you can host (note that form spree is on GitHub too https://github.com/formspree/formspree <https://github.com/formspree/formspree>) > > This last point is where Iâd like Pharo (Zinc, Iceberg) to be integrated. Again we could imagine a web service system based on Zinc. I could manage form submissions that way and everything Iâd like but it may end up complex. Do I need a database ? Do I need to store information and therefore manage the underlying architecture. If it crash, I want only the endpoint to be not available but the whole site still working. > > An in between elegant solution os to use git for what itâs good at (versioning collaboratively through PR, and also reliable hosting in classic platforms). > > The idea is to use the PR mechanisms to submit stuff like blog comments (note that you have a free moderation system). > This is actually not limited to comments but all kinds of possible interactionâ¦ > > This way is (to me) better in terms of infrastructure management. Such a service also needs to be available (and maintained) but this is a very minimalist machinery (hanling POST request service only - no real content management as deferred to github). And again, a fail safe version (for the last version of the generated pages). > > Staticman (https://staticman.net <https://staticman.net/>) is a nice node application that allows to do this. Itâs possible to host the service too. > <GraphiqueCollÃ©-1.png> > > I can use this node app of course, but I believe we could have quite easily such an application in Pharo with Zinc. > I also wonder if we could use Iceberg to deal with this information straight in a pharo image (thatâd be cherry on the cake). > The super cherry of the cake would be pharo core and lib documentation, demos (you can have one gihub page by organization and/or users - in paid plans, you can have more for private stuff)â¦ One place, one process to contribute, either for code or documentation. > > Anyway, I have no real question except than asking for feedback and also to know if some people are interested in such project. > > Cheers, > > CÃ©drick > > nb: my hidden goal is to provide web site for people, unipersonal and small organizations. So you know, they pay for the service of creation, but then they own it and can do whatever they like. Of course we can also offer paid services like managing dynamic information content. More than comments, Iâd like to be able to deal with stuff like orders, facturation, even meeting planning through ics versioned files, etc. > This really is something Iâd like to be able to provide soon (less than 1 yr time - simplest web site with contact form and comments at least). It might become something more serious the future... > >

May 23, 2020

Re: [Pharo-dev] [Pharo-users] Project of Interest => Jekyll + Dynamic processing integration + Git(hubs)Pages => pharo in the middle

by CÃ©drick BÃ©ler

Hi Torsten, > > Hi CÃ©drick, > > You know <https://www.netlify.com> where you can quickly connect to a GitHub project and serve it with a global CDN easily > in seconds as in <https://www.youtube.com/watch?v=mN9oI98As_4> I actually just discovered after sending the email, as Hugo for as a generator too. https://jamstatic.fr/2017/06/07/migration-de-jekyll-a-hugo/ <https://jamstatic.fr/2017/06/07/migration-de-jekyll-a-hugo/> Looks interesting. Iâll try. > > As the site runs HTTPS you can even host quickly a HTML/CSS/JS based PWA application. I tried with React and it works > nicely. So when you push a change to GitHub it easily goes live ... using two branches you can distinquish between prod > vs. dev. > > > No direct need for ruby or explicit site generator - but if you need you can also use Pharo and try "Mustache" or "Templ" and > similar to generate the page. Yes I think itâs doable too and would be great. I donât want to really install Jekyll, more rely on the GitHub integration. So it builds too after a change (the delay might be a problem though for some - thatâs why people prefer hogo + netlify). The idea is to help people build their web site and quickly be able to change without asking me to do it. This is for now mostly for friends and some projects we have to make a web site on (and Iâm often the guy whose asked for doing a simple siteâ¦). > If you want Pharo for a backend or in the middle then either continue running your linux machine or put Pharo into docker and > run it on Azure, AWS or any other cloud based service out there. This way you can raise more instances when traffic raises > and you can scale. Decoupling the services is easy with REST/GraphQL and Pharo has projects to support that (Stargate, > Teapot/Tealight, GraphQL, ...). > > You can even go serverless with Pharo Lambda Ultimate. > > Many, many possibilities these days... Oh yes :). But as I want to keep it really simple, Iâll go for some kind of static site generation. I want people to have a simple vitrine of their activity, with a contact form and a certain feed of article. Iâll explore a bit more this tools so lets discuss it too. > > Have fun > T. You too ;-) CÃ©drick > > > > Gesendet: Samstag, 23. Mai 2020 um 15:13 Uhr > Von: "CÃ©drick BÃ©ler" <cdrick65(a)gmail.com> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org>, "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> > Betreff: [Pharo-users] Project of Interest => Jekyll + Dynamic processing integration + Git(hubs)Pages => pharo in the middle > > Hi there, > > This post is just to talk about one side project Iâm exploring and interested in from a long time. I think it may interest other people here. > > Iâd like to have powerful (static based) web site so hosting is really cheap (even free) and hassle free. Iâve my own server for years, it is cheap and simple but, of course, it needs some maintenance (linux update, nginx scripts, â¦) even if tools are the simplest Iâve found. > > Recently thanks to student projects ;-), I found some time to learn what I find is a wonderful solution. This solution is to use GitHub DSCM, GitHub Pages and Jekyll (a ruby static site generator that is natively integrated) all together. > https://jekyllrb.com[https://jekyllrb.com] > > The beauty is that you can edit the site straight on GitHub. We get the power of version system and hosting for freeâ¦ > It literally is a CMS and the cheapest and reliable that I know of (grav might be another option). > > Of course, there are some Â« dynamic Â» content possibilities too (otherwise GitHub Pages is enough) > - blog posts are natively generated through new files according to a name convention. > - there are plugins too (but you have to watch for compatibility in GitHub). > > Dealing with forms and comments is possible > - solutions that are hosted on a third-party. Solution like Discus or formspree, â¦ (thatâs a NO GO to me) > - web service integration that you can host (note that form spree is on GitHub too https://github.com/formspree/formspree[https://github.com/formspree/formspr…) > > This last point is where Iâd like Pharo (Zinc, Iceberg) to be integrated. Again we could imagine a web service system based on Zinc. I could manage form submissions that way and everything Iâd like but it may end up complex. Do I need a database ? Do I need to store information and therefore manage the underlying architecture. If it crash, I want only the endpoint to be not available but the whole site still working. > > An in between elegant solution os to use git for what itâs good at (versioning collaboratively through PR, and also reliable hosting in classic platforms). > > > The idea is to use the PR mechanisms to submit stuff like blog comments (note that you have a free moderation system). > This is actually not limited to comments but all kinds of possible interactionâ¦ > > This way is (to me) better in terms of infrastructure management. Such a service also needs to be available (and maintained) but this is a very minimalist machinery (hanling POST request service only - no real content management as deferred to github). And again, a fail safe version (for the last version of the generated pages). > > Staticman (https://staticman.net[https://staticman.net]) is a nice node application that allows to do this. Itâs possible to host the service too. > > > I can use this node app of course, but I believe we could have quite easily such an application in Pharo with Zinc. > I also wonder if we could use Iceberg to deal with this information straight in a pharo image (thatâd be cherry on the cake). > The super cherry of the cake would be pharo core and lib documentation, demos (you can have one gihub page by organization and/or users - in paid plans, you can have more for private stuff)â¦ One place, one process to contribute, either for code or documentation. > > Anyway, I have no real question except than asking for feedback and also to know if some people are interested in such project. > > Cheers, > > CÃ©drick > > nb: my hidden goal is to provide web site for people, unipersonal and small organizations. So you know, they pay for the service of creation, but then they own it and can do whatever they like. Of course we can also offer paid services like managing dynamic information content. More than comments, Iâd like to be able to deal with stuff like orders, facturation, even meeting planning through ics versioned files, etc. > This really is something Iâd like to be able to provide soon (less than 1 yr time - simplest web site with contact form and comments at least). It might become something more serious the future... > > >

May 23, 2020

Re: [Pharo-dev] Project of Interest => Jekyll + Dynamic processing integration + Git(hubs)Pages => pharo in the middle

by Esteban Maringolo

Hi CÃ©drik, This comes really on time for me, I decided to rewrite to small sites I have using Jekyll, and as read all their tutorials I thought even of having a Jekyllst variation, that uses the Jekyll directories and other conventions, but uses Smalltalk as its engine. Of course this is far reached given my real availability these days, that's lower than usual. However I'd like to be part of conversations around this, and eventually contribute to it, because I already started playing with Jekyll (and Gatsby as well). Regards, Esteban A. Maringolo On Sat, May 23, 2020 at 10:15 AM CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: > Hi there, > > This post is just to talk about one side project Iâm exploring and > interested in from a long time. I think it may interest other people here. > > Iâd like to have powerful (static based) web site so hosting is really > cheap (even free) and hassle free. Iâve my own server for years, it is > cheap and simple but, of course, it needs some maintenance (linux update, > nginx scripts, â¦) even if tools are the simplest Iâve found. > > Recently thanks to student projects ;-), I found some time to learn what I > find is a wonderful solution. This solution is to use GitHub DSCM, GitHub > Pages and Jekyll (a ruby static site generator that is natively integrated) > all together. > https://jekyllrb.com > > The beauty is that you can edit the site straight on GitHub. We get the > power of version system and hosting for freeâ¦ > It literally is a CMS and the cheapest and reliable that I know of (grav > might be another option). > > Of course, there are some Â« dynamic Â» content possibilities too (otherwise > GitHub Pages is enough) > - blog posts are natively generated through new files according to a name > convention. > - there are plugins too (but you have to watch for compatibility in > GitHub). > > Dealing with forms and comments is possible > - solutions that are hosted on a third-party. Solution like Discus or > formspree, â¦ (thatâs a NO GO to me) > - web service integration that you can host (note that form spree is on > GitHub too https://github.com/formspree/formspree) > > This last point is where Iâd like Pharo (Zinc, Iceberg) to be integrated. > Again we could imagine a web service system based on Zinc. I could manage > form submissions that way and everything Iâd like but it may end up > complex. Do I need a database ? Do I need to store information and > therefore manage the underlying architecture. If it crash, I want only the > endpoint to be not available but the whole site still working. > > An in between elegant solution os to use git for what itâs good at > (versioning collaboratively through PR, and also reliable hosting in > classic platforms). > > The idea is to use the PR mechanisms to submit stuff like blog comments > (note that you have a free moderation system). > This is actually not limited to comments but all kinds of possible > interactionâ¦ > > This way is (to me) better in terms of infrastructure management. Such a > service also needs to be available (and maintained) but this is a very > minimalist machinery (hanling POST request service only - no real content > management as deferred to github). And again, a fail safe version (for the > last version of the generated pages). > > Staticman (https://staticman.net) is a nice node application that allows > to do this. Itâs possible to host the service too. > > I can use this node app of course, but I believe we could have quite > easily such an application in Pharo with Zinc. > I also wonder if we could use Iceberg to deal with this information > straight in a pharo image (thatâd be cherry on the cake). > The super cherry of the cake would be pharo core and lib documentation, > demos (you can have one gihub page by organization and/or users - in paid > plans, you can have more for private stuff)â¦ One place, one process to > contribute, either for code or documentation. > > Anyway, I have no real question except than asking for feedback and also > to know if some people are interested in such project. > > Cheers, > > CÃ©drick > > nb: my hidden goal is to provide web site for people, unipersonal and > small organizations. So you know, they pay for the service of creation, but > then they own it and can do whatever they like. Of course we can also offer > paid services like managing dynamic information content. More than > comments, Iâd like to be able to deal with stuff like orders, facturation, > even meeting planning through ics versioned files, etc. > This really is something Iâd like to be able to provide soon (less than 1 > yr time - simplest web site with contact form and comments at least). It > might become something more serious the future... > > >

May 23, 2020

Re: [Pharo-dev] [Pharo-users] Project of Interest => Jekyll + Dynamic processing integration + Git(hubs)Pages => pharo in the middle

by Torsten Bergmann

HiÂ CÃ©drick, You know <https://www.netlify.com> where you can quickly connect to a GitHub project and serve it with a global CDN easily in seconds as in <https://www.youtube.com/watch?v=mN9oI98As_4> As the site runs HTTPS you can even host quickly a HTML/CSS/JS based PWA application. I tried with React and it works nicely. So when you push a change to GitHub it easily goes live ... using two branches you can distinquish betweenÂ prod vs. dev. Â No direct need for ruby or explicit site generator - but if you need you can also use Pharo and try "Mustache" or "Templ" and similar to generate the page. If you want Pharo for a backend or in the middle then either continue running your linux machine or put Pharo into docker and run it on Azure, AWS or any other cloud based service out there. This way you can raise more instances when traffic raises and you can scale. Decoupling the services is easy with REST/GraphQL and Pharo has projects to support that (Stargate, Teapot/Tealight, GraphQL, ...). You can even go serverless with Pharo Lambda Ultimate. Many, many possibilities these days... Have fun T. Â Â Gesendet:Â Samstag, 23. Mai 2020 um 15:13 Uhr Von:Â "CÃ©drick BÃ©ler" <cdrick65(a)gmail.com> An:Â "Pharo Development List" <pharo-dev(a)lists.pharo.org>, "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> Betreff:Â [Pharo-users] Project of Interest => Jekyll + Dynamic processing integration + Git(hubs)Pages => pharo in the middle Hi there,Â Â This post is just to talk about one side project Iâm exploring and interested in from a long time. I think it may interest other people here. Â Iâd like to have powerful (static based) web site so hosting is really cheap (even free) and hassle free. Iâve my own server for years, it is cheap and simple but, of course, it needs some maintenance (linux update, nginx scripts, â¦) even if tools are the simplest Iâve found. Â Recently thanks to student projects ;-), I found some time to learn what I find is a wonderful solution. This solution is to use GitHub DSCM, GitHub Pages and Jekyll (a ruby static site generator that is natively integrated) all together. https://jekyllrb.com[https://jekyllrb.com]Â Â The beauty is that you can edit the site straight on GitHub. We get the power of version system and hosting for freeâ¦Â It literally is a CMS and the cheapest and reliable that I know of (grav might be another option). Â Of course, there are some Â«Â dynamicÂ Â» content possibilities too (otherwise GitHub Pages is enough) - blog posts are natively generated through new files according to a name convention. - there are plugins too (but you have to watch for compatibility in GitHub). Â Dealing with forms and comments is possible - solutions that are hosted on a third-party. Solution like Discus or formspree, â¦ (thatâs a NO GO to me) - web service integration that you can host (note that form spree is on GitHub too https://github.com/formspree/formspree[https://github.com/formspree/formspr…) Â This last point is where Iâd like Pharo (Zinc, Iceberg) to be integrated. Again we could imagine a web service system based on Zinc. I could manage form submissions that way and everything Iâd like but it may end up complex. Do I need a database ? Do I need to store information and therefore manage the underlying architecture. If it crash, I want only the endpoint to be not available but the whole site still working. Â An in between elegant solution os to use git for what itâs good at (versioning collaboratively through PR, and also reliable hosting in classic platforms).Â Â The idea is to use the PR mechanisms to submit stuff like blog comments (note that you have a free moderation system).Â This is actually not limited to comments but all kinds of possible interactionâ¦ Â This way is (to me) better in terms of infrastructure management. Such a service also needs to be available (and maintained) but this is a very minimalist machinery (hanling POST request service only - no real content management as deferred to github). And again, a fail safe version (for the last version of the generated pages). Â Staticman (https://staticman.net[https://staticman.net]) is a nice node application that allows to do this. Itâs possible to host the service too. Â I can use this node app of course, but I believe we could have quite easily such an application in Pharo with Zinc.Â I also wonder if we could use Iceberg to deal with this information straight in a pharo image (thatâd be cherry on the cake).Â The super cherry of the cake would be pharo core and lib documentation, demos (you can have one gihub page by organization and/or users - in paid plans, you can have more for private stuff)â¦ One place, one process to contribute, either for code or documentation. Â Anyway, I have no real question except than asking for feedback and also to know if some people are interested in such project.Â Â Cheers, Â CÃ©drick Â nb: my hidden goal is to provide web site for people, unipersonal and small organizations. So you know, they pay for the service of creation, but then they own it and can do whatever they like. Of course we can also offer paid services like managing dynamic information content. More than comments, Iâd like to be able to deal with stuff like orders, facturation, even meeting planning through ics versioned files, etc.Â This really is something Iâd like to be able to provide soon (less than 1 yr time - simplest web site with contact form and comments at least). It might become something more serious the future... Â Â

May 23, 2020

Re: [Pharo-dev] uFFI: What is the difference between FFIExternalObject and FFIOpaqueObject?

by Sean P. DeNigris

Esteban Lorenzano wrote > The easiest way I have to explain is: > > You use an OpaqueObject when you will refer to the opaque type in calls > as: someFunction(opaqueobject *someArg). > You use an ExternalObject when you will refer to the opaque type in calls > as: someFunction(externalobject someArg). Very clear! We're getting somewhere :) But... What if a type is used both ways? For example: ^ self ffiCall: #(Method * class_copyMethodList(Class self, uint *outCount)) and ^ self ffiCall: #(struct objc_method_description * method_getDescription(Method self)) ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

May 23, 2020