Introducing the new getters/setters based on vs_fields

.github/workflows/build.yml

@@ -97,6 +97,7 @@ jobs:
         run: scripts/build-default.sh
       - name: Archive production artifacts
         uses: actions/upload-artifact@v4
+        if: failure()
         with:
           name: macos14-meson-logs
           path: |

.github/workflows/docs.yml

@@ -1,6 +1,7 @@
 name: Deploy Docs
 
 on:
+  workflow_call:
   push:
     branches:
       - master

.github/workflows/release.yml

@@ -55,6 +55,7 @@ jobs:
           meson dist -C build/ --allow-dirty --no-tests --include-subprojects
       - name: Add artifact
         uses: softprops/action-gh-release@v2
+        if: failure()
         with:
           files: |
             ./build/meson-dist/**/*

RELEASE.md

@@ -19,6 +19,7 @@ This is what has been implemented so far (and some missing feature for context):
   - [ ] fix linking to follow https://github.com/KaruroChori/vs-fltk/issues/63
   - [ ] debian and arch packages are now supported
   - [ ] install script can be now be safely used
+  - [x] specific features of `vs` can be excluded from building.
 - [ ] New widgets & improvements
   - [ ] flex
   - [ ] grid

TODO.md

@@ -1 +1,3 @@
 - [ ] Allow http only without libcurl via https://github.com/lazy-eggplant/libhttp
+- [ ] Port all enums and serialization functions to the new interface
+- [ ] Replace the usage of the old serialization interface in codegen to match the new one.

bindings/native/include/fixed-types.h

@@ -0,0 +1,24 @@
+#pragma once
+/**
+ * @file vs.h 
+ * @author karurochari (public@karurochari.com)
+ * @brief Just some types to simplify and prettify code.
+ * 
+ * @copyright Copyright (c) 2024
+ * 
+ */
+
+#include <stdint.h>
+#include <stdbool.h>
+
+// Type alias
+typedef __INT64_TYPE__ i64;
+typedef unsigned __INT64_TYPE__ u64;
+typedef __INT32_TYPE__ i32;
+typedef unsigned __INT32_TYPE__ u32;
+typedef short int i16;
+typedef unsigned short int u16;
+typedef signed char i8;
+typedef unsigned char u8;
+typedef float fp;
+typedef double lfp;

bindings/native/include/vs.h

@@ -9,12 +9,17 @@
  */
 
 #include <stdarg.h>
+#include <stddef.h>
+
+#include "fixed-types.h"
 
 typedef  void* node_t;
 
+// VS stuff
+
 extern node_t vs_self;
 
-enum log_severety_t{
+typedef enum log_severety_t{
   LOG_INFO,
   LOG_OK,
   LOG_WARNING,
@@ -25,40 +30,88 @@ enum log_severety_t{
   LOG_LVL_SILENT = 0x10,
   LOG_LVL_VERBOSE = 0x20,
   LOG_LVL_DEBUG = 0x40,
-};
-typedef enum log_severety_t log_severety_t;
+}log_severety_t;
 
-struct __symbol_t{
+typedef struct __symbol_t{
   enum{
     UNKNOWN=1, CALLBACK, DRAW, SETTER, GETTER,
   } mode:3;
   enum{
     NATIVE=1, QUICKJS, WASM, EXTERNAL, LUA
   } type:5;
   const void* symbol;
-};
+}__symbol_t;
 
-typedef struct __symbol_t __symbol_t;
 
-
-struct symbol_ret_t{
+typedef struct symbol_ret_t{
   __symbol_t symbol;
   __symbol_t ctx_apply;
   const void* found_at;
-};
+}symbol_ret_t;
 
-typedef struct symbol_ret_t symbol_ret_t;
 
-struct vs_field_t{
+typedef enum vs_types_t{
+  TYPE_FLAG=1,
+  TYPE_ENUM,
+  TYPE_RAW,
+  TYPE_PATH,
+  TYPE_CSTRING,
+  TYPE_STRING_VIEW,
+  TYPE_COLOR,
+  TYPE_ISCALAR_1,
+  TYPE_ISCALAR_2,
+  TYPE_ISCALAR_3,
+  TYPE_ISCALAR_4,
+  TYPE_FSCALAR_1,
+  TYPE_FSCALAR_2,
+  TYPE_FSCALAR_3,
+  TYPE_FSCALAR_4
+} vs_types_t;
+
+
+typedef struct vs_field_model_t{
   const char* name;
   int(*setter)(const char*);
-  int(*getter)(char**);
-};
-
-typedef struct vs_field_t vs_field_t;
-
-
-//extern int printf(const char*restrict, ...);
+  int(*getter)(const char**);
+} vs_field_model_t;
+
+typedef struct vs_field_t{
+  u32 type: 22;
+  u32 valod: 1;
+  u32 need_cleanup: 1;
+  u32 subtype: 8;
+
+  union{
+    int               FLAG;
+    size_t            ENUM;
+    void*             RAW;
+    const char *      CSTRING;
+    struct{
+      void* ptr;
+      size_t size;
+    }                 STRING_VIEW;
+    u8                COLOR[4];
+    u32               ISCALAR_1[1];
+    u32               ISCALAR_2[2];
+    u32               ISCALAR_3[3];
+    u32               ISCALAR_4[4];
+    fp                FSCALAR_1[1];
+    fp                FSCALAR_2[2];
+    fp                FSCALAR_3[3];
+    fp                FSCALAR_4[4];
+  }storage;
+
+} vs_field_t;
+
+
+
+extern vs_field_t* vs_field_make();
+extern void vs_field_destroy(vs_field_t* obj);
+
+inline int as_flag(vs_field_t* field){
+  //TODO: throw() if runtime type not equal to flag
+  //return payload reference
+}
 
 extern int vs_log(int severety, node_t self, const char* string, ...);
 #define $$log(self,sev,string, ...) vs_log(sev,self,string, ##__VA_ARGS__)
@@ -108,17 +161,3 @@ extern void vs_debug(const char* key, const char* value);
 
 //Extra functions
 char* itoa(int value, char* result, int base);
-
-enum vs_types_t{
-  TYPE_UNKNOWN,
-  TYPE_FLAG,
-  TYPE_ENUM,
-  TYPE_RAW,
-  TYPE_PATH,
-  TYPE_STRING,
-  TYPE_COLOR,
-  TYPE_SCALAR_1,
-  TYPE_SCALAR_2,
-  TYPE_SCALAR_4
-};
-typedef vs_types_t vs_types_t;

dist/website/index.html

@@ -24,6 +24,8 @@
             gap: 1.0em;
             flex-direction: column;
             max-width: 600px;
+            padding-top: 1rem;
+            padding-bottom: 1rem;
         }
 
         nav button {
@@ -57,6 +59,10 @@
             <button disabled>Online demo</button>
             <button disabled><i class="fa-solid fa-comment"></i> Help</button>
         </nav>
+        <hr />
+        <figure>
+            <h6>Versions: <a href="../latest/">latest</a>, <a href="../next/">next</a></h6>
+        </figure>
     </main>
     <footer>
 

docs/developers/building.md

@@ -1,7 +1,7 @@
 > [!IMPORTANT]  
 > It was decided that distribution & building will be split.  
 > Distribution is to be handled [here](https://github.com/lazy-eggplant/vs.autobuilds), while everything build-related stays.  
-> This also includes docker images, since they are not meant for final users but developers of `vs` and its related subprojects.
+> Docker images are excluded, as they are meant for developers of `vs`, not distribution of the final runtime.
 
 ## Supported platforms
 
@@ -24,31 +24,45 @@ In addition to this, the building environment is also distributed via docker ima
 
 ### Distribution
 
-There are plans to distribute both **stable** and **nightly** releases of vs. Please, be mindful that nightly releases can be extremely broken, and for safety reasons they will only be offered as flatpaks.
+There are plans to distribute both **stable** and **nightly** releases of vs.  
+Please, be mindful that nightly releases can be extremely broken, and for safety reasons they will only be offered as flatpaks.
 
-Distribution formats which are expected to be supported at some point:
+Distribution formats which are supported:
 
 - `flatpak` targetting the latest stable freedesktop environment
+
+Distribution formats which are expected to be supported (at some point):
+
 - `deb` for the latest stable and experimental of debian (multiarch)
 - `aur` for arch linux and derivatives
 - `brew` for macos
 
-Installing directly via meson is very much not suggested if you don't want to break your system.
+Installing directly via `meson` is very much not suggested if you don't want to break your system.
+
+## Configuration flags
+
+Configuration flags, like for any meson project, are in `meson.options`.  
+In brief, you can disable most features of the runtime if you so wish.  
+This can be good to meet specific safety targets by removing some available options, or to optimize it on embedded applications where the overhead of some parts might be excessive.
+
+Builds distributed from this repository are based on the default options unless explicitly specified.
 
 ## Building requirements
 
 You will need a proper Linux environment, with a modern C++ toolchain installed.  
 Specifically, I suggest `clang-19` or higher, as this repo is using modern C23 features like `#embed` to make everyone's (my) life a bit easier.
 In addition to that, this repo makes use of:
 
-- [meson](https://mesonbuild.com/) as its main build system. Any recent-ish version will do (unless you need `zig` to simplify cross-compiling; for that >= 1.60 is needed)
+- [meson](https://mesonbuild.com/) as its main build system. Any recent-ish version will do (unless you want `zig` to simplify cross-compiling; for that, >= 1.60 is needed)
 - [bun](https://bun.sh/) as the ts/js runtime to support all the code generation tasks and some of the more complex pipelines.  
-   I hate bash, and this is what replaces it.
+   I hate bash, and this is what replaces it for any complex task.
 - [swiftc](https://www.swift.org/documentation/swift-compiler/) barely used for now, but many of the native components shipped within `vs` will be written in swift (or so I am planning). Version 6 or higher is needed.
 
 ### FLTK
 
-If your system provides a modern version of `fltk>=1.4`, that will be used by default. If not present, you are likely needing few more [dependencies](https://github.com/fltk/fltk/blob/master/README.Unix.txt) depending on your distribution. On debian-like systems the followings are needed:
+If your system provides a modern version of `fltk>=1.4`, that will be used by default.  
+If not present, you are likely needing few more [dependencies](https://github.com/fltk/fltk/blob/master/README.Unix.txt) depending on your distribution.  
+On debian-like systems the followings are needed:
 
 - **libpng-dev**
 - **libglu1-mesa-dev**

docs/developers/contributing.md

@@ -1,15 +1,17 @@
 ## Structure of the repo
 
 - **src** where most of the source for **vs.app** and the **vs.fltk** library are located.
-- **include** like before for the header files. Directories are mostly mirrored.
+- **include** like before for the header files. Directories mostly mirrors what is in `src`.
 - **schemas** high level specs, main source of information for documentation and automatic code-gen.
-- **commons** extra public files (some auto-generated) which are part of every **vs** distribution.
+- **commons** extra public files part of every **vs** distribution (some of them are auto-generated).
 - **docs** & **examples**: this documentation & and all examples. As part of the build process, they are shipped as part of the commons.
 - **bindings** bindings for all languages supported in embedded `script`.
 - **test** & **benchmark**: test suite & benchmarks for **vs** & the **vs.fltk** library.
 - **scripts** utility scripts (mostly in TS/JS) to handle code generation, the build process and some workflows.
 - **experiments** playground where new ideas or semi-standalone prototypes are tested.
 - **metadata** information for distribution (icons, manifest files etc.).
+- **dist** most of these files are automatically generated and not tracked, the rest of them are needed to distribute the final website with docs.
+- **docker** anything related to the docker images used to build `vs`.
 
 ## Language & format guidelines
 
@@ -103,4 +105,4 @@ As such:
 - They must be written in [CommonMark](https://commonmark.org/) (with some possible extensions like the block headers for notices or warnings).
 - They shall not include HTML within them. XML will be parsed as normal `vs` code.
 
-Files which are written in markdown, but are outside the `docs` can follow a more relaxed format and target github/gitlab extensions for visualization.
+Files which are written in markdown, but are outside the `docs`, can follow a more relaxed format and target github/gitlab extensions for visualization.

docs/developers/ideas/expected-new-getters.md

@@ -0,0 +1,14 @@
+```xml
+<component>
+    <script lang="c">
+        int set_name(const void*){}
+        int get_name(void*){}
+
+        $field {
+            "name",
+            set_name,
+            get_name,
+        }
+    </script>
+</component>
+```

docs/developers/todo.md

@@ -1,14 +1,5 @@
 ## Missing for release 0.1.1
 
-### Flatpak issues
-
-- [ ] libfltk and its subdeps are compiled into `/app/lib64`, which is not covered by paths
-      Investigation got results. Basically, all cmake libraries are in `/app/lib` while those through meson are in `/app/lib64` which is not added to the search path in that image.  
-       Even outside of flatpak this problem occurs, just with different folder names. I must ensure cmake and meson behave the same.
-- [ ] commons are not mounted in `/usr/local/share`. I must pass the relevant vars (already supported).  
-       I must register a variable in the user with where these files are located? Or embed it during compilation? Still not sure.
-- [x] Icons, signature and few more things are still missing.
-
 ### Scripts
 
 - [x] turn off (for now) app linking capabilities

docs/faq.md

@@ -1,3 +1,7 @@
+---
+title: FAQ
+---
+
 ## General questions
 
 ![Good luck with vs!](./assets/hero-img.webp)

docs/full-specs/data.md

@@ -0,0 +1,30 @@
+# Data
+
+Data elements are the main and most idiomatic mechanism in `vs` to include state in applications.
+
+## General structure
+
+### Attributes
+
+- **readonly** as boolean. Defaults to `false`. If true, no mutation is allowed from within this application.
+- **volatile** as boolean. Defaults to `true`. If true it must be expected that events outside the scope of this app can change data.
+- **src** as string. The source path of data. It must be specified.
+- **schema** as string. The source path to a schema file. Used as metadata for static checks when the associated datasource is used.
+
+## Subtypes
+
+### CSV
+
+#### Additional attributes
+
+- **header** as boolean. Defaults to `false`. If true the first row is used as schema information or skipped if `schema` is already provided.
+- **separator.field** as string. Defaults to `\t`. The character to split columns.
+- **separator.record** as string. Defaults to `\n`. The character to split records.
+
+### FS
+
+### JSON
+
+### SQLITE
+
+### XML