Forum Replies Created
-
AuthorPosts
-
Oh my, thanks nerobot! Never noticed…
Alrighty, not a problem. I’ll try and work around this for now.
I’m not in any position you give you any official information, but in short; anything can happen next with Monkey.
Long Answer: Mx2 is becoming extremely flexible and far more integrated with pre-established technologies. Recently an automated “wrapping” tool was released to make use of popular C API’s in Monkey, this will enable nearly any API to be “converted” to Monkey given enough initial effort and community support. Honestly, I can see it becoming one of the best things to have in your programming arsenal, alongside C/++ though not a replacement.
That said, as for the next few months. We can definitely expect a lot of interesting discussion on language concepts and Mark will hopefully be in the lab follow his heart in implementing more “core” features while the community uses his tools to amplify Monkey even more based on the discussion.
Personally, I’m experimenting with creating a Linux User Space(command-line tools/basic computing applications) within mostly Monkey code JUST to see if it can be done. xD So far my research is promising! No promises though. Haha.
I’ve noticed the release build is 1.6mb instead of 2.9mb. I understand that most of the debug related functionality is being ignored by the compiler.
As for “#Include” and “#Import,” this would be a great opportunity to use “#Include” for including only sub-modules instead of the full core module, in the need of only a few parts of std, mojo/x, or any other library in use. Reducing compile size in the process.
So if you need ALL components of the std module just use #Import “<std>” and if you need only specific parts like “filesystem,” and “collections” for a simple App. You can; as an expample…
Note: Not sure if this is happening in the release build, but just an idea.
Monkey1234567891011121314151617#Include "<std/core>"#Include "<std/filesystem>"#Include "<std/collections>"' Versus:'#Import "<std>"' Using/compiling only what has been "INCLUDED".Using std..Function Main()' CodezEnd FunctionDuplicate variables are in principle still not good. I just love K.I.S.S.
I’ve always wanted to make my own Distro, and try and fix a few things I’ve noticed such as the Environment Vars. Pre-load it with a nice looking, light weight GUI(Openbox or XFCE/LXDE) with the some of the user-space written in mostly in Monkey2. No way I could do it myself. xD
Addition: I’m running the new Zorin OS 12 Core. And I don’t have a “USER” just a “USERNAME” and a “LOGNAME”
I’ll switch it to “LOGNAME” since both of our distros support it.Monkey12345678Function GetEnv:String(value)Local variable:libc.char_t Ptr = libc.getenv(value)return String.FromCString(variable)End FunctionFunction Main:Void()Print(GetEnv("LOGNAME"))End FunctionUSERNAME is for Linux. xD Sorry forgot to mention that. xD
Monkey12Local USERNAME:libc.char_t Ptr = libc.getenv("USERNAME")Print(String.FromCString(USERNAME))Sorry I didn’t realize I used the wrong Environment Variable to retrieve. I meant “USERNAME” xD
“String.FromCString” is what I need! Thanks so much!
That only seems to only convert an Array of Int’s to their to Unicode equivalents…
OMG! That’s exactly what I was looking for! I’ll rebuild on Linux and check it out.
Best. Support. Ever!
Thank you so very much Mark!
You’re absolutely right! Knowledge is power these days. xD
Wow. *super facepalm*
Well I guess I know more about hex and binary now. xD Thank you Mark and everyone else. xD
Oops. 4 not 8. Noob mistake. xD Gotta convert those strings. Haha.
Thank you for the info. I checked your Fork out and compiled it on Linux under GNOME 3.22. Keep it up! No issues I can see right off the bat.
-
AuthorPosts