~grtcdr

Tunis

https://grtcdr.tn

Computer science undergraduate, libre software developer and amateur gardener.

Trackers

~grtcdr/giornata

Last active 7 months ago

~grtcdr/darkman.el

Last active 10 months ago

~grtcdr/carrara

Last active 1 year, 5 months ago

~grtcdr/citron

Last active 1 year, 5 months ago

~grtcdr/paspio

Last active 1 year, 5 months ago

~grtcdr/liaison

Last active 1 year, 5 months ago

~grtcdr/dyna

Last active 1 year, 5 months ago

#55 Modify an existing subdirectory of a website 25 days ago

Comment by ~grtcdr on ~xenrox/hut

maybe you can ask in IRC or on the mailing list.

Okay, I'll do that.

Otherwise you could create a new dedicated folder for assets which get uploaded by a different pipeline. Then you would not overwrite your other files.

This leads to unwanted redundancy; I could create a cv subdirectory but then the path to the file would look like /cv/cv.pdf.

#55 Modify an existing subdirectory of a website 25 days ago

Ticket created by ~grtcdr on ~xenrox/hut

Greetings,

I'm trying to figure out a way to update one file in my website without overwriting the existing contents of that subdirectory.

Some more detail: I'm attempting to upload a file (a curriculum vitae) from one pipeline into a pre-published website (sourcehut pages) (handled in another pipeline).

This build log builds the curriculum vitae, places it in a tar archive (such that the only thing contained within is a cv.pdf file) and runs:

 hut pages publish cv.tar.gz --domain grtcdr.tn --subdirectory assets

I had expected hut to unarchive the tar file and place its contents in the website's assets subdirectory, what in fact happened was that hut overwrote the whole directory and then placed the cv.pdf file. I was therefore able to access cv.pdf but not some of the other files that were originally contained there.

I'd really appreciate it if hut could take use case into account, as that would really simplify making modifications from outside pipelines.

#2 add a hook for when the mode is changed 10 months ago

Comment by ~grtcdr on ~grtcdr/darkman.el

You're very welcome :)

REPORTED RESOLVED CLOSED

#2 add a hook for when the mode is changed 10 months ago

Comment by ~grtcdr on ~grtcdr/darkman.el

Hi,

I've implemented your request in commit ecbeeee3b596123755ebb2d2b4bc0399b086ccbf.

-- Aziz

#2 add a hook for when the mode is changed 10 months ago

feature added by ~grtcdr on ~grtcdr/darkman.el

#1 darkman-mode fails to ping dbus service at times 11 months ago

Comment by ~grtcdr on ~grtcdr/darkman.el

REPORTED RESOLVED NOT_OUR_BUG

#1 darkman-mode fails to ping dbus service at times 11 months ago

Comment by ~grtcdr on ~grtcdr/darkman.el

magically the issue resolved itself due time

Good to know, I'll close the issue then.

#1 darkman-mode fails to ping dbus service at times 1 year, 1 month ago

bug added by ~grtcdr on ~grtcdr/darkman.el

#1 darkman-mode fails to ping dbus service at times 1 year, 1 month ago

Comment by ~grtcdr on ~grtcdr/darkman.el

also the automatic switch of everything but emacs (which is i think able to switch once but not back eg to black theme but not to white back i am pasting the debug log in case you might be interested)

I'm not sure I understand the problem, could you please reformulate?

Debugger entered--Lisp error: (error "nl.whynothugo.darkman D-Bus service not available") signal(error ("nl.whynothugo.darkman D-Bus service not available")) error("%s D-Bus service not available" "nl.whynothugo.darkman") darkman--dbus-service-unavailable-error() darkman--check-dbus-service() darkman-mode(1) custom-set-minor-mode(darkman-mode t) custom-theme-recalc-variable(darkman-mode) enable-theme(user) enable-theme(modus-operandi) load-theme(modus-operandi) darkman--load-theme(modus-operandi) darkman-set-theme() darkman-mode(1) custom-set-minor-mode(darkman-mode t) custom-theme-recalc-variable(darkman-mode) enable-theme(user) enable-theme(modus-operandi)

I've flipped the stack trace for a more natural analysis, let's see what's going on.

So, you've run `darkman-toggle' interactively,

execute-extended-command(nil "darkman-toggle")

which internally invokes darkman-current-mode' whose result will be reversed and passed as a parameter to darkman-set-mode'.

This is confirmed by this next function call in the stack trace,

darkman-set-mode(light)

which tells us that the D-Bus daemon replied with "dark" and thus `darkman-set-mode' is instructed to set the mode to its opposite, i.e. "light".

This is good news, we are able to communicate with the D-Bus daemon, but something else is going wrong later on in the stack trace.

The last function call should have triggered a "ModeChanged" event, which we can confirm from

command-execute(dbus-handle-event nil [(dbus-event :session 4 2557 ":1.23" nil "/nl/whynothugo/darkman" "nl.whynothugo.darkman" "ModeChanged" darkman--signal-handler (:string "light"))] t)

which would execute a callback function

apply(darkman--signal-handler "light")

loading the corresponding theme

load-theme(modus-operandi)

What I understand from this is that darkman-toggle' works correctly. What doesn't work is darkman-mode' whose first invocation works as expected, but fails on the second due to what I presume is a timeout in the ping operation between the two applications (Emacs and Darkman).

I don't know what could be causing this ping timeout or why the behavior of `darkman-mode' is unpredictable.

I also can't reproduce this problem on my machine, so I'll keep the issue open in the hopes that someone more knowledgeable than me could help us figure it out.

#1 darkman-mode fails to ping dbus service at times 1 year, 1 month ago

Comment by ~grtcdr on ~grtcdr/darkman.el

Hi,

darkman--dbus-service-unavailable-error: nl.whynothugo.darkman D-Bus service not available

Can you please ensure the Darkman daemon is working properly before Emacs is started?

Making requests to a D-Bus object will activate the corresponding D-Bus service if it wasn't already activated, this explains why things start working when you've manually toggled `darkman-mode' yourself.

If you're using systemd, run the following in your shell:

systemctl is-active --user darkman.service

The command will print "active" if the service is running without issues.

#Regards,

Aziz