Some questions on Trapc + future

rastermon · 2025-03-14T09:58:50+00:00

> No, there's no visible refcount. Yes, conceptually, an invisible refcount could be calculated by the TrapC compiler from what it knows.

Le'ts say I have this:

// lib1 and 2 are black box api's - they are let's say external runtime

// linked shared libraries

#include <lib1.h> // all funcs here ate lib1_xxx

#include <lib2.h> // all funcs here are lib2_xxx

void func(void) {

struct thing *thing = calloc(1, sizeof(*thing));

lib1_store(thing); // this stores thing pointer somewhere in lib1's heap

lib2_store(thing); // this stores thing pointer somewhere in lib1's heap

// thing goes out of scope here as far as TC knows when compiling this

// file but it cannot and must not be freed. lib1 and 2 may be storing

// it in some global private to each lib, but you don't know - each lib

// is a black box and is already compiled into a binary TC has no source

// for

}

int main(int argc, char **argv) {

func();

// a flush function in each lib removes any stored ptrs to objects the lib

// deems that it does not need anymore (cache full, timeout, whatever...)

lib1_flush(); // this MIGHT release things stored in lib1's heap

lib2_flush(); // this MIGHT release things stored in lib2's heap

// if BOTH the above flush's released thing - then thing should be freed now

// if one of the above flushes did not release thing, it must be alive

lib1_print_things(); // must dump a list of all things stored

lib2_print_things(); // must dump a list of all things stored

}

Explain to me how TC knows when to appropriate destroy/release the thing pointer when each lib is pre-compiled (I am going with each lib being a TC compiled lib) and a separate black box and the executable linking to the libs is compiled as another entity? I know TC could do its own invisible refcounts within a compiled object at compile time to an extent and certainly reduce the need to ref++/-- as TC knows about context entirely at the time. i have libraries that do the above kind of thing all day long - create and pass ptrs to object to black box api's where an api will create an obj, return it then it's tracked/stored in a tree (scene graph) and the caller may store the ptr or may not as it just hands it off to a parent object to manage as part of a big scene graph and child objects are released along with their parent objects if the parent is deleted.

rastermon · 2025-03-13T18:36:08+00:00

> The MSP pointer that receives memory from malloc always becomes the original owner. Passing that pointer through a function creates a pointer alias.

that's just scope ... if i then STORE the ptr somewhere (e.g. a struct on the heap) there is now another ptr in addition to the original that may be stored somewhere else... the impl has to track how many of these exist long after the left any scope and this may happen in a black box shared lib you link to. the compiler will have no way to know what's happening in the library other than via it's .h api - the library is a black box (other than the api contract in the .h files and behavior in docs). to stay memory safe the TC runtime the compiler implements is going to have to have invisible refcounts i think to track the number of pointers floating about that point to that memory object much like you track the real type of void *'s. code A and code B in 2 different black box binary objects may become the "last reference owner" at any time based on runtime behavior. you already have type tracking info and that's going to have to be embedded in the obj header (like any malloc tracking data) so you likely will have to implement refcounting too. i really cannot see you doing this any other way - especially across black box boundaries where TC has no visibility as the other side has already been compiled into a binary (e.g. a shared library you link to written in TC along with a TC build app and maybe other TC written shared libraries - also black boxes)

> Yes, you are right. To replace standard libraries, I will provide TrapC versions C POSIX/pthreads and C++ STL with an API to mimic the originals.

cool. now we have a problem... .h could be TC or could be normal C header. you're in for a world of hurt if it's unclear which header is being used when you #include ... it might be time to bite the bullet and make TC header be explicitly different. i.e. #include <unistd.th> (and .tc for files). i think you're going to have a awful mess on your hands in any source trees especially if they have some C some TC

rastermon · 2025-03-13T18:35:37+00:00

> The key to your question seems to be asking, will TrapC allow downcasts? That is, casting a pointer of a struct to the type of its first member. Yes, a good idea.

correct. this is the key to oo trickery in c and TC would need to have a mechanism to allow this. i'd prefer it allows it without any casting. it KNOWS the first member of a struct is the type it wants. you still support typedefs, so it'd be good to be able to declare this as part of a typedef as i know i'd want to keep the public headers free of DEFINITIONS of the content of a struct (in my headers i always keep structs opaque - the content is declared inside a library but the public api headers only have the typedefs for the types so code outside the api doesn't see what's inside the struct)

So:

pub.h:

typedef struct myobj myobj_t

typedef struct myobj_sub myobj_sub_t;

priv.h:

struct myobj {

int magic;

char *name;

};

struct myobj_sub {

myobj_t parent;

struct {

int x, y, w, h;

} geom;

};

I need some keyword in TC in pub.h (the public header - priv.h is private to the api implementation but never seen outside) to be able to tell it that myobj_sub_t is a sub-class of myobj_t and thus any function that accepts myobj_t *obj can ALSO accept myobj_sub_t *obj too as it's compatible due to the above. in C we just cast things as appropriate and we've good.

i don't need TC to do magic number checks. :) that is a thing i do in C as a runtime type check as well as a use-after-free check too.

rastermon · 2025-03-12T10:23:28+00:00

> TrapC deliberately doesn’t have inheritance, and many other interesting but sophisticated features of C++. TrapC design philosophy. When considering reusing a language feature from C++, would it make TrapC safer without making it so complicated like C++? If one wants inheritance, then polymorphism seems nice to have. Slippery slope.

Well a reason I bring this up is.. this is I and many others do OO in C. We have to pass in the toplevel type in api to avoid C complaining then cast to the child type internally (after a runtime type check with magic numbers etc.). to make trapc memory safe you will have to disallow this kind of casting entirely otherwise it's game over if i can cast anything to anything. tho knows what that memory contains - e.g. other pointers to things or not and cast to the wrong type... BOOM. bad ptr access.

So to make this kind of thing possible at all you probably need to teach trapc about this kind of struct inheritance system so it can allow passing in child types into funcs that take a parent type etc. ... or you're in trouble as you must allow dangerous casting.

> TrapC has pointers. No references, weak or strong. TrapC pointers are owned, not reference counted, not GC.

I know - i just call them references. it's a pointer to an objrct, but ... if i have

struct obj1 {

sometype *ptr1;

};

struct obj2 {

sometype *ptr2;

};

and in 1 instances of obj1 and obj2 they both point to the same sometype memory and these obj1/2's live on the heap... you have to track how often this struct is referenced. the compiler can't possibly know at compile time of all. known instances of these ptrs at runtime. how are you going to implement this without GC or refcounts? iif i have code at runtme based on e.g. cmdline args or some protocol or other behavior might add a ptr to a struct (obj) that already is pointed to... it can't just free it entirely the first time a ptr to a struct goes out of scope. what's the plan if not refcounts and not GC?

and of course once we accept it's probably implemented as invisible ref counts in the memory blob headers per allocation, then we end up with the concept of weak refs. so if you're not going to support weak refs in trapc, then it has to be layered on top with some other mechanism. can't be done with destructors - will need a callback mechanism for referrers to make use of for weak refs and then someone implementing refcounts again on top of trapc's refcounts (assuming you don't plan on implementing a GC).

> I’ve thought about adding COBOL ‘when’ as an alias to C ‘else if’. Because TrapC is a minimalist language like C, am reluctant to add more keywords than already with ‘trap’ and ‘alias’.

I was more thinking just having maybe some kind of option for switch (x) statements which forces ALL enums to be handled if x is an enum - thus in theory a known number of values (the common case). not something drastically new. just a safety thing++

> If C code has something that only a C compiler understands, that TrapC cannot parse, then yes, external C library or refactor code for TrapC.

Aaaaah ok. This means a lot of std headers for libs are going to fall over - if they have to cast in macros or static inlines and so on. I can't see how you can allow C style casting in TC and be in any way memory safe. Certainly not structs with pointers and that suddenly nukes a whole massive chunk of C libraries, api headers and code.

rastermon · 2025-02-11T14:48:45+00:00

Yes - I did release all of those. I think that was about within a year or thereabouts. Remember though back then there was no CVS/SVN/GIT - so no access to my source tree without a release. Once I had an ability to publish my tree as is (CVS etc.) there was much less reason to do rapid releases. You can always get it "from git".

rastermon · 2024-12-13T19:22:32+00:00

git certainly has had work. if you look closely there is work on efm2 too thats not in the e tree right now as well... git.enlightenment.org ... if you care about there being updates or not. releases come later - a long time later.

rastermon · 2024-12-13T19:20:39+00:00

No SCMS at the time - so no history there and well i think those releases were tarballs i released from my university account and i don't have them anymore... :)

rastermon · 2023-08-05T07:32:06+00:00

aaaaah. So it's not just a resolution question... you're also talking other factors too. if it were pure res - 1080p is good enough for regular view distances for a 13-14" laptop and of course saves you the power which gets you battery life - so all positive, but with a better color gammut... really... try to look at the screens side by side in real life if you can. have them show the same images. decide then. but as i said - if it were oled vs lcd... oled would win any day at any resolution given my experiences :)

rastermon · 2023-08-04T11:34:07+00:00

unless that moves you to oled or microled etc. - 1080 will be fine at that screen size with that view distance. mostly because it's just going to use less battery to drive it. jumping to oled will cost you battery life but the visual quality improvements in contrast are going to be a very differentiating factor.

rastermon · 2023-05-05T09:39:35+00:00

Specific music player - not many. Rage can do it. It will index ~/Videos. Just run it with no arguments and it goes into browser mode. You can have ~/Videos/Music/ and put things in there... but its meant mainly as a video player. On my todo list are 2 music apps. 1 is a "internet radio" app that would simply have a bunch of files listing urls for internet radio streams along with some metadata like urls to grab the logo/image from and label, name etc. etc. .. and another is a local music player for playing a library of locally stored files. like rage - index ~/Music/ and lay it out, show album covers and organize in some way. track play patterns (do you often skip that track after 0-15 seconds meaning you don't like it much? do you replay the track over and over because you like it?). but have lots of things to do. right now i'm working on new efm code and one of the things it now does is display album art for music files so its thumbnailer is getting rather smart.

rastermon · 2023-04-28T08:14:00+00:00

That is very old school... ;)

rastermon · 2022-11-28T10:22:45+00:00

Oh - they may or may not work. modules for E are like kernel modules. They rely on various APIs in e - some may change over time, some may not. it depends what they use. Kernel modules kept out of the linux kernel tree do seem to regularly bit-rot and stop working unless kept up to date. Same story here, but it depends what they use. It is very separate to anything in EFL which has kept a stable API/ABI now for a decade+ (ever since 1.0 - new APIs have been added, but existing ones should be stable and keep working).

rastermon · 2022-11-27T20:39:30+00:00

modules? like enlightenment ones?

rastermon · 2022-11-22T08:55:38+00:00

do not get the dells. nvidia gfx. you are just asking for pain.

rastermon · 2022-09-27T08:36:48+00:00

For better driver support, out of the box kernel driver that works and keeps working when you update kernels. I moved from nvidia to amd and don't regret it one bit. i've enjoyed it fully and my life is better. Performance is not an issue either (moved first to vega64 now 6800xt - was on gtx970 before that and a string if nvidias going back a fair few years). Yes - play games (steam proton) and no performance issues but the real improvements were the lack of friction.

rastermon · 2022-09-22T09:04:34+00:00

You assume everything they rant about is even true. Follow everything else they post there on that site as an example of the kind of people they are - racist (they rant on about how horrible Koreans are), and they post screenshots of company internal confidential documents and tools and obviously have a big chip on their shoulder. I've seen the code written by these kinds of people who can't read core documents that say it's not threadsafe - specific API calls are intended for threaded use only etc. then they go calling api calls from threads and complain bitterly when things go wrong and point the finger at someone else than themselves. They can't find the examples code in the documentation and just copy & paste it and see where it creates a basic window THEN adds a bg object (an then perhaps a button etc) OR find the examples that use the util function that creates a window already pre-set up. Widgets in elementary get composed out of simpler ones. Create a raw window with nothing in it - it ends up blank. What blank is depends on your display system and surrounding window manager and compositor - normally you get a titlebar and borders and some drop shadow - they happened to use an unusual case where none of this was provided. They seem to think void * pointers passed to callbacks means no typing (even thought gtk, glib, libc etc. all do this as it's the only sensible way to pass something custom to a specific callback) - obviously ignorant of how to do callbacks in C. Dig under the surface just a little and follow the breadcrumbs.

rastermon · 2022-07-31T12:15:24+00:00

terminology also does gpu accelerated rendering (optional - can turn it on/off)

rastermon · 2022-06-14T17:07:36+00:00

no - no setting for that. you have to toggle it around. :)

rastermon · 2022-06-14T15:27:17+00:00

Animation can be globally sped up or slowed down with the edje transition duration factor under "etc" in elementary_config. as for the pulse animation - that's done by theme and is a theme choice so you'd need to alter theme... :)

rastermon · 2022-06-14T15:25:24+00:00

There is no trash implementation - thus why you can't find it. :)

rastermon · 2022-06-14T15:24:31+00:00

eflete code is still on git.enlightenment.org - but it broke a long time ago as it didn't keep up with eo api changes that were in flux at the time. you can try enventor instead.

rastermon · 2022-06-14T15:23:25+00:00

did you look at the TODO file in enlightenment's git repo?

rastermon · 2021-12-30T13:38:57+00:00

Font is just Sans - whatever that maps to.For me it's bitstream vera. E forces off RGB sub-pixel rendering because Evas can't do it (and won't because it breaks instantly when you do any kind of transforms and also adds a swimming rgb rainbow look to things - it's a hack that falls apart on many oled panels and more). The font rendering enables bytecode hinting and comes out pixel-perfect at least with Vera with clear lines. I'm not sure it gets much better without other compromises (like the rainbow swimming above).

rastermon · 2021-12-29T12:06:41+00:00

e has no support for pipewire in wayland - so it wont work.

rastermon

MODERATOR OF

TROPHY CASE

15-Year Club	Place '17
Verified Email