@vbabka after some testing and "unfixing" mbsync bug [1] I don't think it is yet ready for production use but sure going to try the latest main every once in a while and might even fix a bug or something.

Normally I hate the whole "Rust fork scene" but in the case of IMAP sync there would be really an actual need for a modern robust alternative. Maybe even something that would handle both IMAP and EWS in the same package. And also email is somewhat fuzzy data to make deductions of so a strong type system can actually make a difference here.

[1] https://social.kernel.org/notice/AkX1oAnWFMXja3uN84

@laamaa I did one test track with polyend couple of years ago but got frustrated of 1.6 fw envelope glitches. Planning to do some new stuff with 1.8 but I need to switch the encoder first, which unfortunately went loose (duh) ;-) New encoder has been waiting on table already for some months...


https://soundcloud.com/triplaespresso/sivutie

https://www.youtube.com/watch?v=CBqQlubSLXs

@rjzak Personally I think that this can be at most taken as a guideline. In some cases Python could be also the best possible solution. It also requires less heavy CI than many other options. E.g. I could imagine doing a real-time embedded system based on MicroPython, and take full control of GC and flush it only in planned call sites.

One critical angle towards #AI from my side is that software engineering is not about producing code.

Even if I wrote all my code in Notepad and slowed my productivity down on purpose let's say to 10%, it would not affect much to my ability to deliver all that much.

The thing is that analysis is the key with minimum amount of false positives, and AI is not an #algorithm.

@rjzak Or like, if IDA Pro was Emacs, this would like "vim" or something ;-)

"best of both worlds" aka Cutter using #Ghidra 's decompiler. RT @rjzak

learning #cutter with trivial crackme's #rizin

@jamborm Yeah and obviously if I have bandwidth I will investigate mbsync sources further!

It is not just my main job :-)

@jamborm Looked into mbsync first time today in source level so this is best I could do in a short noticed and can read my email again so worth of investment.

I also checked GCC 13 later on:

1. LLVM 18 without the fix: works
2. GCC 13 without the fix: works
3. GCC 14 without the fix does not work.

@Noremak Yes!

@Noremak Also surprisingly producing some music in the past also helped because also in that you tend deduce stuff from frequency distributions. And also I've written a couples of 3D engines in the past, which has helped a lot understanding unit transformations :-) Enjoyed so far because I really need to stretch all my experience to get shit together in my head (and without being a physician).

Just sharing my experiences for anyone who might give a shot in this area. The mindset with semiconductors is computing. The mindset with quantum IMHO is observation (when put to a single word).

@Noremak I still know nothing about physics but that was the whole point of this learning experiment because in the end of the day it must detach out of physics literature in order to be successful. Early days of semiconductor programming was also more tied to the physics so I expect similar development here.

I've studied algebra and discrete math so I know the binary side, and also vector analysis and linear algebra a bit, so combining that knowledge and thinking superposition states as base transformations helped a lot to cope the topic. It is a game of unit vector spaces with complex factors or that is how I see it like for a regular programmer (like me).

@Noremak My high school friend is one of the founders of a quantum computer company called IQM: https://www.meetiqm.com/. He is quantum computing professor at Aalto University in Helsinki.

https://www.youtube.com/watch?v=m0GqCxMmyF4

Here’s my #mbsync #GCC workaround for #Fedora:

commit ebf6bcea7ebdba15553692777d292e59ec1d5e2e (HEAD -> master)
Author: Jarkko Sakkinen <jarkko@kernel.org>
Date:   Thu Aug 1 21:36:37 2024 +0300

    work around a GCC-14 optimizer issue
    
    mbsync throws SIGSEGV in sync_opened(). As it turns out for some
    reason the second entry in the local array 'boxes' is optimized
    out:
    
    (gdb) print boxes
    $1 = {0x5555556c4540, <optimized out>}
    
    Fix this by pinning the variable using a dummy inline assembly
    statement:
    
    __asm__ __volatile__("" :: "m" (boxes));
    
    This sets an invariant, which should guarantee that the compiler
    leaves 'boxes' untouched.
    
    As a comparative measure mbsync was compiled also with clang without the
    fix, and the resulting ELF binary does not have this issue.
    
    Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2302132
    Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>

diff --git a/src/main_sync.c b/src/main_sync.c
index 226e324..afb23ca 100644
--- a/src/main_sync.c
+++ b/src/main_sync.c
@@ -623,6 +623,7 @@ sync_opened( main_vars_t *mvars, int t )
        if (!mvars->chanptr->boxlist && mvars->chan->patterns) {
                mvars->chanptr->boxlist = 2;
                char **boxes[2];
+               __asm__ __volatile__("" :: "m" (boxes));
                boxes[F] = filter_boxes( mvars->boxes[F], mvars->chan->boxes[F], mvars->chan->patterns );
                boxes[N] = filter_boxes( mvars->boxes[N], mvars->chan->boxes[N], mvars->chan->patterns );
                box_ent_t **mboxapp = &mvars->chanptr->boxes;

Also attached to https://bugzilla.redhat.com/show_bug.cgi?id=2302132

@adamw @gromit I compiled mbsync from upstream without my workaround using clang, and that version works also without glitches, so I'm pretty sure that this might be an actual GCC 14 bug..

@adamw @gromit It totally works now. Creative workarounds...

(gdb) print boxes
$1 = {0x5555556c4540, <optimized out>}

I noticed this so I tried:

diff --git a/src/main_sync.c b/src/main_sync.c
index 226e324..afb23ca 100644
--- a/src/main_sync.c
+++ b/src/main_sync.c
@@ -623,6 +623,7 @@ sync_opened( main_vars_t *mvars, int t )
if (!mvars->chanptr->boxlist && mvars->chan->patterns) {
mvars->chanptr->boxlist = 2;
char **boxes[2];
+ __asm__ __volatile__("" :: "m" (boxes));
boxes[F] = filter_boxes( mvars->boxes[F], mvars->chan->boxes[F], mvars->chan->patterns );
boxes[N] = filter_boxes( mvars->boxes[N], mvars->chan->boxes[N], mvars->chan->patterns );
box_ent_t **mboxapp = &mvars->chanptr->boxes;

That literally fixed the bug! I.e. could this be a #GCC bug?

RT @gromit, @adamw

#mbsync #gcc #fedora #bug #isync