Kaj de Vos
-
Posts
443 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Everything posted by Kaj de Vos
-
Meta programming language on Bluesky social network
Kaj de Vos replied to Kaj de Vos's topic in Atari 8-Bit Computers
Nice that you're trying it! I run M-COIL.XEX on Atari800 on Linux myself preferably, without problems. Did you turn up the brightness of your screen? The demo is just single pixels on a black background. Are you running Linux on something else than AMD/Intel 64-bit? Otherwise, the binaries for the compilers are here: https://language.metaproject.frl/#APE You only need the Blink VM on other systems, and you only need to compile Blink from source on obscure systems. -
Previous post here Meta is now on Bluesky: bsky.app/profile/language.metaproject.frl Bluesky is a new, open social media network. It is designed as a distributed system, without a central point of control. No more censorship, no more deplatforming, no more forced advertising. You control your own attention by subscribing to what you want and filtering out what you don't want. We will be microblogging our announcements there, and building a community. You can follow us to be informed of our posts. The first engineer of the Protocol Labs and early Bluesky advisor is already a follower: bsky.app/profile/language.metaproject.frl/followers When others post using the #MetaLang tag, we will be able to follow all Meta posts across the network: bsky.app/hashtag/MetaLang
-
Arnold van Hofwegen published a nice collection of documentation and example programs for Meta: https://language.metaproject.frl/documentation/ https://language.metaproject.frl/examples/
-
Previous post here Good news! The Meta programming language secured its first funding for further development of the language. The development is sponsored by New York Link. The build service and tools will be developed further. The Meta compiler currently supports multiple targets: - Atari 8-bit, through the compile.com command-line tool; - Web browsers, through the web console; - Popular PC platforms, through the run.com command-line tool. While the build service is already universal, the tools are not. The compile.com tool will be extended to support multiple target platforms. You will be able to compile for PC without needing to run the resulting program. This is also a necessary preparation for releasing more target platforms for cross-compilation, such as Atari 2600. The build service will actually benefit from being less universal. We will set up an extra build server in, you guessed it, New York. This will ensure our customer will have the best latency and performance for compiling Meta programs. This is the kind of thing we can do for sponsors. If you're interested in funding your particular wishes, please contact us throught email to discuss it: https://language.metaproject.frl#contact
-
The CC65 library stack is one of the causes, but it's not just that. CC65 derives from an old compiler design that doesn't do many optimisations. Some constructs do generate better code than others, but you have to change your program code to use those constructs. Typical C code doesn't compile very well.
-
Chances are the source code needs a lot of tweaks to force CC65 to generate more efficient code. Not only faster, but also smaller.
-
Made a series of improvements to the web console: https://console.metaproject.frl Layouting of long error messages is improved. Several bugs in the Meta web backend were fixed. Thanks go to iArnold from the REBOL scene for testing.
-
List-XEX automatically adapts between command-line environments and menu-driven environments such as Atari DOS. Here it analyses itself running directly on the Atari800 emulator, without a DOS: This is treated like a menu-driven environment, because the emulator also clears the program output after it runs. Because there are no command-line parameters, List-XEX asks for the file name interactively. The emulator's H: device is used here to read the file from the disk of the host system. After the program is done, it asks for a key press to preserve the output. Some more info: On Atari, List-XEX needs 32 KB of RAM. It could run on a stocked up 800 or upgraded 400 or 600XL. While reading the input file, it uses a buffer that can buffer a full track of a double density floppy disk, to speed up operation on floppy drives without a track buffer. The program loads at address $2600 to leave room for optional extra drivers. For example, this is enough to load the FujiNet N: handler above regular Atari DOS, so List-XEX can access files on the Internet and other networks.
-
List-XEX automatically adapts between command-line environments and menu-driven environments such as Atari DOS. Here it analyses itself running directly on the Atari800 emulator, without a DOS: This is treated like a menu-driven environment, because the emulator also clears the program output after it runs. Because there are no command-line parameters, List-XEX asks for the file name interactively. The emulator's H: device is used here to read the file from the disk of the host system. After the program is done, it asks for a key press to preserve the output. Some more info: On Atari, List-XEX needs 32 KB of RAM. It could run on a stocked up 800 or upgraded 400 or 600XL. While reading the input file, it uses a buffer that can buffer a full track of a double density floppy disk, to speed up operation on floppy drives without a track buffer. The program loads at address $2600 to leave room for optional extra drivers. For example, this is enough to load the FujiNet N: handler above regular Atari DOS, so List-XEX can access files on the Internet and other networks.
-
Yes, I probably used Bill Wilkinson's tool in BASIC at the time, or perhaps I already made something to desegment Mac/65 files, I don't remember. In any case, it's a basic tool, that I missed in the CC65 toolchain, so I wanted it back in Meta, and it's a good next step in its evolution.
-
It can be hard to grasp other people's motivations, but when I had an XEP80 on my Atari, it was because I wanted to see more content on the screen. For example, if you use List-XEX on a file produced by Mac/65, you would get lots of 256-byte segments. It's very useful if they don't scroll off the screen. List-XEX is a portable text-mode program, mainly for command-line environments. Colouring text mode is hard on Atari, so this is far outside the scope of List-XEX. Showing the file name is just a feedback to the user how his or her command-line parameters are interpreted. Especially because they can also be interpreted as commands.
-
I don't know what you mean. Again, the layout is optimised and the text of the built-in help is optimised. If you mean it doesn't have to be, then yes, it doesn't have to have this feature, but it does have this feature. In the case of the file name, it gets its own line on 40 columns to allow for longer file names, for example including directory paths, or FujiNet network paths.
-
Look closer. The leading information uses fewer lines. In a future version, I will put more info on a line, but this is the version that was frozen at the ABBUC's deadline. The previous screenshots of the built-in help have completely different layout and different text between 40 and 80 columns.
-
Here is the portable binary version of List-XEX running on Linux, analysing the Atari binary version: Again, it automatically adapts to the larger screen, also if you have 80 colums on your Atari.
-
Here is the portable binary version of List-XEX running on Linux, analysing the Atari binary version: Again, it automatically adapts to the larger screen, also if you have 80 colums on your Atari.
-
Here is List-XEX analysing itself: It shows all values in decimal and hexadecimal. It recognises initialisation and run vectors and shows their addresses.
-
Here is List-XEX analysing itself: It shows all values in decimal and hexadecimal. It recognises initialisation and run vectors and shows their addresses.
-
Meta has all of that, as I have shown here many times. If you don't care about half of it, you can use the other half - as happens in many languages. Meta has control over program size, hardware control, speed and an integrated assembler. If you think 29 bytes for a graphics demo is Iarge, I would like to see you beat it. I still think it's very presumptuous of you to pretend to speak for everyone here. Let people speak for themselves, and they express it in their interest in the Meta threads here. I guess you're the kind of person who goes to China and then complains in English to the people there that their language is unclear because it isn't obvious to you. I do agree that people who are not interested in using Meta, keep refusing to make an effort, and keep ignoring my explanations and advice, have no business responding here.
- 127 replies
-
- 1
-
-
- programming-language
- compiler
- (and 10 more)
-
List-XEX works on Atari 8-bit and on modern PC platforms: Windows, Apple MacOS, Linux, FreeBSD, NetBSD and OpenBSD, using the exact same program source code. It even uses the same binary executable file on all modern systems. Here it shows its built-in help on Linux: It automatically adapts to the larger screen and makes use of an 80-column display instead of 40. This is not only useful on PC platforms, but also if you have some kind of 80-column display on your Atari.
-
List-XEX works on Atari 8-bit and on modern PC platforms: Windows, Apple MacOS, Linux, FreeBSD, NetBSD and OpenBSD, using the exact same program source code. It even uses the same binary executable file on all modern systems. Here it shows its built-in help on Linux: It automatically adapts to the larger screen and makes use of an 80-column display instead of 40. This is not only useful on PC platforms, but also if you have some kind of 80-column display on your Atari.
-
This is exactly the problem. If you are not familiar with any language from the Logo family, you can not expect it to work to project pre-conceptions from other language families onto it. That has nothing to do with this issue. It doesn't matter if you don't read documentation now, or not last year, or not next year. It's not going to work for you, no matter what state the language is in. If anything, if it takes years to get people to read documentation, it was right to start that early.
-
@thorfdbg, no offence taken. I'm trying to analyse your feedback to see if there is anything in there that warrants changing the language, or if I can somehow formulate documentation to address these concerns. However, the REBOL design has been meticulously thought out for more than three decades, so usually I end up making only small tweaks. What's completely different in Meta is the implementation. What I must keep repeating, is that these are all basic questions, that can simply be answered by reading the REBOL documentation. Most people who don't know REBOL seem to prefer to avoid the documentation at all cost and make up their own misconceptions. We know that as RTFM, we know it doesn't work, and writing more documentation doesn't solve this problem, either. For example, I agree that your proposal of counter modulo 3 equals 0 would be closer to English, and have a nice linear execution order. Meta is able to implement any language, so it could be done by making modulo and equals operators. This could be done with all binary methods. There are several reasons why this is not done in the default functional language dialect: Not all binary methods are eligible, for example if condition [statements]. It can't be a general rule. There already are operators to achieve this form: counter % 3 = 0 With few exceptions, there is a convention to use English words for methods and math symbols for operators. This is important to distinguish the different language forms. So to achieve the form you favour, the advise is to use the math operators. I wish that were true. Control flow structures in C are not expressions, and that is the hardest thing for Meta to generate C. It would be opaque if it were true. There seems to be a pattern that your first instinct is right, but then you don't see how it works under the hood and you start making up constructs that are too complex and are not there. This can be solved by studying the REBOL documentation. The modulo expression is an argument to unless just as it is written, there is no "survival" of this expression, there is no "T-junction" and there is no syntactic sugar for things that aren't there. The flow of values, expressions and control in Meta is very simple and straightforward, even simpler than in REBOL. Every syntactic element is a thing! (value in REBOL). Every thing! is either a literal value or a method. Every potentially composite construct is an expression. Every expression returns a value (thing!). A method can take parameters, which are (sub-)expressions. A method can implement a control structure on its sub-expressions. Therefore, a method taking parameters can transform these into a different return value. unless takes a condition expression that it interprets as logic!, and a block of generic expressions of which it takes the last value. With those, it infers its return type. You can call it a junction, but every method does this, in a straightforward way. There is nothing different about any. It takes one argument: usually a literal block! of sub-expressions. In FizzBuzz, it happens that the last expression of the code blocks of both unless and any return nothing!. For unless, it means it has to construct a logic! return value out of that. any is used as a statement here, so it doesn't have to return a value, so that automatically becomes nothing! and it doesn't matter. This is all inspired by and similar to Lisp, accept that this Logo family of languages supports infix operators, to allow code closer to human language, as you also requested in your example.
-
That's fine. The ABBUC is funding Meta's development with prize money, so they currently get my top priority.
-
https://language.metaproject.frl/#when If you want to make writing more Meta documentation my top priority, you are welcome to contact me privately to fund it.
-
https://language.metaproject.frl/documentation/
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord