Re: [Pharo-users] Some facts and figures about pharo gaining momentum?
You can check the github repos, github allows you to browse project repos per language. You could probably automate that from Pharo, use the Github API like Iceberg does fetch the names of all projects using smalltalk language and check to see which ones have commits the last year and then make a nice graph using Roassal. You could do that also periodically to track the growth in popularity. Github is the center place for everything open source, Pharo and Squeak are more tricky because they each have their own hosting sites squeaksource for Squeak and smalltalkhub for Pharo but I think most modern Pharo projects seem to have made the jump to github too. But even with Smalltalkhub there should be some API lurking in there although I suspect it will be undocumented and a lot trickier to get it working. Another source is Google trends, but I dont think google search is very reliable because smalltalk is a regular word that is not 99.99% of the time used to mean the programming language, so you will have to use terms like "smalltalk programming" (this is the primary method that the TIOBE INDEX is using for all its languages) but even that wont be very reliable. Technically speaking language popularity is a can of worms, there is a huge disagreement even which are the TOP 10 most popular programming languages right now. Even the TOP 3 can widely fluctuate. So as you can imagine keeping track of something as unpopular as smalltalk is going to be quite a challange. For example "everyone" seem to agree that there is very little reason nowdays to use C over C++, cause "C++ is a much better C with objects" , on the other hand language popularity websites seem to disagree with "everyone" because not only they have C in top 10 but in many cases its more popular than C++ and to put more insult to the sin they also show it shrinking way slower than C++ in popularity. Such an example is TIOBE https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/c/ https://www.tiobe.com/tiobe-index/cplusplus/ If we cannot even agree with C vs C++ imagine Smalltalk vs The REST. But I think Github API is a good place to start. The worst place to start is asking people for opinion and reading blog posts , hackernews, twitter, facebook or whatever else "hipster" thing, especially stackoverflow and medium. In the end language popularity is a hopeless cause. In theory everyone cares, in practice, none does. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Re: [Pharo-users] Its too hard to contribute to the Iceberg wiki
Another solution is to clone the wiki, it offers its github link and then make a new repo for the wiki alone and upload the files which are regular md files (github markdown). The good news is that you wont be losing any of the conveniences because github offers a markdown editor with live previews , the only you will be losing will be the automatic table of contents but that can be hosted as a seperate md file. I have done this for creating a Wiki for Pharo you can find the example here https://github.com/kilon/PharoWiki/blob/master/README.md This can also be implemented as a branch to a project, usually the branch is named "gh-pages" but I dont think there is a restriction you can host the wiki then as a website which will be available using a link very similar to .github.io or orgname if its a organisation. If it's done this way you and everyone else will enjoy all the privileges of a regular github repo. Because is markdown it's also compatible with gitlab and gitbooks , gitbook can take a wiki and easily turn it to a book with export to pdf etc. Is just a matter of setup, the default way of github wikis is not to give you access to such advanced features and instead prioritize ease of use. If you want full nuclear power then a regular github repo is the way to go. Of course "advanced mode" will give you also easy access to using Pillar or whatever you want to use. Frankly PR seems a bit overkill for a wiki, becoming a contributor to the wiki repo would make your life a lot easier with direct access to editing the md files online without the whole trouble of git pull, push, pull requests etc. But of course all that is up to Iceberg devs I started Pharo wiki as an experiment and it worked much better than I expected and of course far better than a regular Github wiki. Ease, straightforward and super flexible. I am more a Gitlab user nowdays but its the same workflow there too. Tim Mackinnon wrote > Ok - my love affair with Github ends at the wiki - what a load of $%$%^$%… > there is no sane and easy way to fork a wiki, make some changes and then > submit a PR. (how the hell did they get into that state?). > > Can we agree to scrap the wiki Iceberg wiki and just have a longer > readme.md > (with sections of the current wiki?). Or if someone can explain easy > instructions for both me (as a contributor) and the admins of iceberg then > I’m all ears…. > > If not - I’ll submit a PR with my subtle changes to the readme. > > Tim Quoted from: http://forum.world.st/Its-too-hard-to-contribute-to-the-Iceberg-wiki-tp5080884.html -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Re: [Pharo-users] A new idea for a project: WarpSpeed (a C inliner)
That does not change the fact that you will have a FFI overhead. For example pyOpenGL 2 was implemented using the Python C API as a wrapper to OpenGL pyOpenGL3 was implemented using ctypes, the official FFI of python (cpython in particular) . Version 3 is 2 to 3 times slower than version 2. But then a FFI also has much lower maintenance cost which is the reason why they moved to a FFI implementations. Its really a difficult problem to solve and there is no blue pill solution. In my case I dont need to because Unreal has already a nice visual scripting language but I want to use Pharo with Unreal. FFI is not an option since unreal builds its own executables and I dont want to hack the engine even though its open source. So I even considered making my own language on top of pharo that will compile to C++. But obviously that is a very big effort and would mean sacrificing a lot of nice things about pharo syntax. So now I fall back to my initial "lazy" solution of shared memory files. Share memory between Pharo and Unreal , let those two process communicate via the share memory and then save the shared memory to a file so I don't lose live state. Relative easy to do since OS already support and provide such functionality. The pro: is that you can still use Pharo as it is and have access to any C++ functionality the con: you have to do all the manual work of mapping Pharo messages to C++ functionality, both at pharo but mainly at the C++ side. However your post made me wonder if I can still invent a programming language like LLVM IR, something that will be basically a protocol of communication between Pharo and C++ and even support onboard features of Unreal like GC, reflection, hot code reloading, blueprints , game editor etc. It looks like that will be the direction I will be going afterall. Seems much simpler, easier and practical than anything else. -- View this message in context: http://forum.world.st/A-new-idea-for-a-project-WarpSpeed-a-C-inliner-tp4881273p4881952.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] A new idea for a project: WarpSpeed (a C inliner)
TinyC has not similar perfomance to gcc and clang, its actually slower as Stephan already mentioned. Thats the price one has to pay for the much smaller compiler, it loses a lot of optimisations. Clement from what you saying its clear my idea would not work at all, the advantage of tinyC is that is 10 times faster than gcc and clang for compilation but the FFI overheads would kill performance indeed. And if the code becomes much larger it does not make sense to use a C inliner as it would be cleaner and easier to just keep the C code separate. Ben TinyC has been abandoned by the original author but it is now even more actively developed because several people have stepped in his place , its git repo can be found here http://repo.or.cz/w/tinycc.git its not near as actively developed as gcc or clang of course but its not inactive either. Anyway this is obviously a ton more work than I am willing to invest and with no real benefit, so thanks for opening my eyes. Back to something far more simple. -- View this message in context: http://forum.world.st/A-new-idea-for-a-project-WarpSpeed-a-C-inliner-tp4881273p4881469.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
[Pharo-users] AST documentation
Is there any documentation for the Pharo AST and any ways to affect Pharo syntax ? -- View this message in context: http://forum.world.st/AST-documentation-tp4877909.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] Compiling Pharo to C++
"Then I guess you can do something like Slang, which is used for the VM. Slang is a restrictive Smalltalk compiling to C. " I dont think Slang is close to what I am trying to do, last time I checked Slang out it appeared to me that Slang is trying to create as much smalltalk syntax as possible. My goal is the other way around to create C++ code by sticking as close to C++ syntax as possible but still using syntax that will make porting pharo code easier. " The slang compiler parses the code using the Smalltalk Compiler parser, then translate the Smalltalk AST to its own AST, " Yeap thats the approach I am interested into as well. Take the Smalltalk AST and translate to an AST very close to C++. I am not interested into creating an in between language. "I am not saying that slang is a nice language and that you should do something similar. Slang is horrible. " Why Slang is horrible according to you ? "But in the case of the VM is has some significant advantages over C++ and method templates." Indeed the VM is awesome but as I said my main goal is not to keep the pharo features but rather to produce very readable C++ code. So I have little problem sacrificing those features. I probably end up making my own variant of the Pharo language that can happily coexist with the existing pharo language. "Not entirely true [1] [1] https://forums.unrealengine.com/showthread.php?3958-Scripting-Language-extensions-via-plugins " Still Pharo is no Lua and it cannot embed itself. What I meant was that its not actively supported. Also its not that simple because one has to expose C++ to the scripting language. I rather have something that produces C++ and I can easily integrate. Or maybe there is something I am missing here and its far easier than I assume. Even without your link embeding lua and python in existing C++ executable is not that hard. Those language offer good support for this and they are heavily used for this task. I also spoke with Esteban about embedding pharo and he told me that pharo has a long way to go before it is able to do this. So for the time being I will start playing around with the Pharo AST and see if I can start generate super simple C++ code out of it and see how hard really it is and move step by step, thank you all for the suggestions. -- View this message in context: http://forum.world.st/Compiling-Pharo-to-C-tp485p4877898.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] Compiling Pharo to C++
"Hi Kilon, the way your are explaining it, it seems you are trying to build a Smalltalk-like syntax in C++ via templates? It could make moving a software architecture from Smalltalk to C++ significantly easier (and open maybe some opportunities). Thierry" Bingo ! You get it ! Thats what is all about about moving code from Pharo to C++ and NOT reimplementing Pharo in C++ as some people assumed. Yes if I can go for smalltalk-syntax that would be a fair compromise, ideally i want to keep Pharo syntax intact and introduce C++ features like static types , pointers etc through the use of pharo objects. For example I can make an object to represent a C++ int, what stops me from taking pharo class variable make it initialise with that int object then later on use a string instead ? Nothing, my compiler wont even complain, but when you turn it to C++ code and try to compile it you will get C++ errors. On the subject of templates, again there wont be magical transormation of dynamic types to C++ templates at least not in the start since C++ expect to be explicity about the use of a template that will carry on to my tool as well. That means that the pharo code will have to be explicit and leave nothing to chance like a C++ coder does. Essentially you coding C++ using pharo syntax or pharo like syntax depending on how succesful I will be with this. Also creating readable code is a must do. For example I have taken a look at chicken and gambit scheme that take scheme (lisp variant) and turn to C and then call the c compiler to make the machine code executable. The problem is that C code is unreeadable because it tries to emulate dynamic types etc. My goal is so not to retain Pharo features and dynamism but rather to produce C++ that is not only readable but proper C++ code with comments , good names, etc. My thinking however is like this: 1) Prototype in Pharo and make sure it works well using all the features and tools of pharo (dynamic types, GC, live coding, live debugging etc) 2) convert your code to my language that looks a lot like pharo but with all the C++ features leaving no ambiguities for the compiler 3) use my compiler to turn a specific fragment of code to C++ 4) go back to to (1) 3) -- View this message in context: http://forum.world.st/Compiling-Pharo-to-C-tp485p4877838.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] Compiling Pharo to C++
"Are you sure C++ compilation is the best way ? There are a lot of flaws: Smalltalk needs to be restrictive or will be compiled to very slow code, you will loose debugging features, etc. I would try to integrate Pharo the same way lua is integrated in engines like Source2 from valve: you run your Unreal engine and have it call Pharo as a scripting language to code some features. In such case, one needs to make the VM embeddable in a C++ app, but on the vm-dev mailing list people can help you to do so. Then you need to define some APIs based on what exist in the interpreter proxy to easily call Pharo methods and share struct / objects from C++. Lastly, you may consider adding a few settings in FFI. By default the Smalltalk stack and the C stack are separated to to Smalltalk specific stack page handling. I guess with some annotation in Pharo API code called from C++ you could define the case where the stack could be shared or not. While compiling to C++, how to you plan your compiler to manage memory ? " I am not able to use Pharo as scripting language for Unreal I am afraid the easy way. I cannot use FFI for reason I describe later on. How I plan my compiler to manage memory , it wont, the compiler will expect very close to C++ syntax and features, it will do minimal work at its side so it will be up to the coder. "I think you totally underestimate the task. Yes, Pharo (Smalltalk) is a pretty simple language (by design), so given a parsed AST (thanks Opal) it will not be so hard to transpile into some other language. But Pharo (Smalltalk) is much, much more: you need a sophisticated runtime (basically the VM) and a large part of the core libraries. Many people have worked very hard for decades to give us what we have today, this represents a huge amount of developer years. " I think you overestimate what I am trying to do, I am not trying to recreate Pharo. There wont be a reimplementation of the VM , or the pharo libraries. This is a simple tool that take pharo-like and turns it to C++ making zero assumptions. That means it will be up to the coder to make sure that what it makes is proper C++. It wont be a magical tool that takes pharo code and turns it to C++ no matter what. There will be a ton of limitations on how you write the code to make sure it produces readable and proper C++ code. The advantage of using it over pure Pharo code ? NONE !!! and NOT RECOMMENDED !!! The advantage of using it over pure C++ code ? a) prototype in pure Pharo code using all the advantages and tools of Pharo IDE b) turn it to pharo like C++ code without having to rewrite your code from scratch in C++ "even for C, there is no compiler that takes Pharo code and compiles it to C - binary code. what slang and vmmaker is doing, is more like a preprocessor, generating C - source code. Compiling C to code is done by an ordinary c-compiler, not smalltalk." we call it "compiler" when we have a tool that take one input and turns it to another output. I am well aware that the compiling is done by ordinary C compiler to machine code. I did not mean that I want to compile pharo code to machine code, but pharo code to C++ code and to be precise Unreal friendly C++ code. "AST for pharo code is not used in any step generating vm code or FFI glue code AFAIK" The way I understand it is that AST is used to take pharo code and brake it down to individual part that is the feed into bytecode compiler and the vm then turns bytecode to machine JIT or interprets it to machine depending on the optimisation. Again I am not concerned with the binary part this is taking one source code and turning to another source code, so it has nothing to do with VM, FFI and machine code. "If Unity does not provide a c-binding, it is really difficult to interact with it through a FF-interface. C++ code uses (theoretically every c++ runtime its own) different naming scheme for functions. You can not load and call c++ code the same way as for C. " My engine is Unreal not Unity. Unreal assumes that you either write C++ code or using their own scripting language "Blueprint". Its not designed to be used as a library so making wrappers for Pharo via FFI is not possible. The main reason is that iOS allows only for static executables. -- View this message in context: http://forum.world.st/Compiling-Pharo-to-C-tp485p4877832.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] Compiling Pharo to C++
Ok first my apology to people because I see that many have misunderstood my motivation. So let me be crystal clear. *This IS NOT an effort to make Pharo "super cool". "Look mom Pharo compiles to C++ magically, it runs blazzing fast, it can use C++ libraries with zero efforts" and similar none sense.* Unfortunately I cannot use Pharo as a scripting language that would be awesome but I afraid not possible. Compiling Unreal as a set of dlls is somewhat possible but the problem is that iOS does not allow dlls, iOS support is super crucial for me so that goes out of the window. Embeding Pharo in Unreal is no go either since pharo does not support this. I am not looking into bringing Pharo features to C++. For example I dont care about dynamic types because Unreal depends a lot on templates which are very dynamic, I dont care about Pharo GC because unreal has its own GC, I dont care about Pharo reflection because Unreal also gives C++ reflection features, I dont even care about Pharo live coding because Unreal also allow to hot reload on the fly when you recompile C++ code. WARNING !!! I am not saying that coding C++ in Unreal is better , more dynamic or more live than Pharo. Pharo is awesome. So my thinking is like this, I cannot avoid C++. So since I cannot avoid it then maybe I could try to make it more enjoyable by making it move closer to pharo syntax. That means my implementation will do a lot of nasty compromises, meaning manual memory managment, disallow dynamic types (though later on with the help of templates maybe I can make it more dynamic) , have to include headers etc. So in general write C++ code using something that is close to pharo syntax. My goal is not an ideal solution but a practical solution something that is relative simple to make for a single developer. It wont be a tool you guys will be using because it will be too tied to Unreal anyway and it will contain the nasty parts of C++. The idea will be similar to what Cython is for python, start prototyping in pure python with all the great features it has, then when code works as you expect start inserting static types, manual memory management etc to turn it to C++. I hope now I am much more clear what I aiming for -- View this message in context: http://forum.world.st/Compiling-Pharo-to-C-tp485p4877821.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
[Pharo-users] Compiling Pharo to C++
So doing further research into Unreal , I have reached the conclusion that the best way to integrate Pharo is make a compiler that takes Pharo code and compiles it to C++. I have barely scratch such area when I was playing around with Pharo AST nodes. Any advice / ideas how to accomplish this ? Currently my goal is to start super simple, with compiling small pharo code fragments to C++ code and then much later on even introduce extensions to the pharo language to accommodate for C++ features like templates , pointers (FFI probably already cover this) , static types etc. Obviously if I can keep the pharo syntax intact would be the ideal option. -- View this message in context: http://forum.world.st/Compiling-Pharo-to-C-tp485.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] Pharo and OpenMP
Thanks for posting the link to the original post , I tried to find it but I failed. On the matter why people did not reply is probably because the idea is too "vague" and very "theoretical" and probably because the post is long. Just for the record I have since dismissed as an idea both the C-image and shared memory model. The bad news is that Apple does not allow one executable to run another executable in iOS which means the pretty much kills the very foundation of my idea and makes it impossible to use Pharo with Unreal on iOS. OpenMP wise again, I found out that Unreal has its own threading model which is very easy to use and runs under the hood. So I dont need that either. "I guess you won't avoid session management with this idea of memory mapped C-image, since the external resources provide from the OS like files, display buffers, network buffers & GPU threads would still be destroyed by the OS when Pharo exits. Consider the case of moving your Pharo-image + C-image to another machine. " No session management is still necessary , the goal was not to make it redundant but rather to keep live state of the C side. But that of course that means that this would not work automagically , the C code will have to use the shared memory mapped file or else the state would be lost. You will need a session manager to trigger the functions that were running at the time the c image file was closed but those functions would be able to continue from where they were left since the state would be restored. "Just to clarify (for myself also if someone likes to correct me) I have gathered the idea that Slang should be thought of less as Smalltalk compiling to C, and more as C with Smalltalk syntax which works well with our usual tools. So compiling Slang to C is "trivial" compared to compiling general Pharo code to C. The trick I guess would be dynamically generating and compiling the C code and then linking it back in. " No not really, its actually the first. Slang has a lot of things C can do that slang cannot do this is why much of the VM is written in C and not Slang. There you expose another weakness of my idea that Slang would need an overhaul to do what I want. "I think applying some kind of OpenMP pragma to random parts of the image's code would be quite difficult because it of the interaction with the VM - but if it was restricted to code that ran detached from the image (e.g. in a separate native or on a GPU) then that could be interesting -- but I can't think of how you would marshall parameters and results between them. " it should not be a problem since the threading would happen in the separate process that VM does not depend on , pharo would have only access to the shared memory. So basically it would be like Pharo: C calculate this with X many threads and when you finish share the result in this part of the memory C : Sure buddy in a few minutes you will have your result , i will alert you Pharo: Thanks mate. In any case that was a pure "theoretical" idea, I posted here to find its weaknesses. I see now its not such a good idea as I initially though for the above reasons. It looks like I wont be using Pharo so much with Unreal afterall since the only viable solution would be to embed it which currently is not possible at least the easy way. Oh well I may still use Pharo here and there to automate some Blender and Unreal stuff :) -- View this message in context: http://forum.world.st/Pharo-and-OpenMP-tp4874277p4875558.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] [ANN] First release of FFICHeaderExtractor
Thanks Mariano, this one may become handy as I am messing a lot with C/C++ lately :) -- View this message in context: http://forum.world.st/ANN-First-release-of-FFICHeaderExtractor-tp4874378p4874683.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
