When I built workdash, its goal and vision wasn't immediately clear to all people. So I thought it could be interesting for people that's don't immediately see it to read the principles and frustrations that made workdash what it is.

On my daily life I maintain and contribute to multiple opensource projects and work repositories, which means I constantly juggle git repos, issue trackers, CI, reviews, terminals, coding agents, logs, and random operational tasks.

In the past I tried to keep up with all of this in many different ways: Emails, GitHub Notifications, Aggregators, the classic “I’ll just ignore everything, if it’s really important someone will ping me” mantra and even more odd automation I won’t share here because would only make your life worse and not better (no, really, don’t try to delegate your life organization to an agent).

None of those worked really for me, because most developer dashboards try to solve this by replacing your workflow with their workflow.

Your editor becomes secondary. Your terminal disappears. Git becomes a button inside somebody else’s UI. Eventually the dashboard becomes the place where everything must to happen.

The question I found asking myself most frequently was "why can't I just open a shell here?"

This is more or less the story of how that question lead me to create "one more tool" and how maybe someone else will find it useful too.

cross-posted from: https://infosec.pub/post/46083169

Hello,

I’m here to ask for guidance on an ongoing project. A number of years ago I wrote an Articles of Association for a worker’s cooperative as I think it should run. The main difference between a conventional co-op and mine is that a conventional co-op tends to have no hierarchy while in mine there is a CEO who gets elected periodically based on their business plan. The theory is that this brings democratic ideals into the workplace without sacrificing the productivity gains that result from hierarchical teamwork. You can read more detailed information on my Beehaw Post.

To put it into practice I need to create an open-source enterprise application server with applications specifically designed for the management of these companies. I created a block diagram to show you what I envision (attached to the post), and this represents my ideal “wish list” for what it should include.

The controls listed at the bottom will determine the permissions everyone has on the network and will be used to design GUI screens. I was going to draw connectors to each of the services but it would have turned into spaghetti.

I’m pretty decent with local programming including database and GUI design, but I lack experience with network programming.

So far I think I need to use XMPP for the messaging client and SSH for the rest. Since I’m most comfortable in Python I was going to look into Paramiko.

So my question is, where should I go in my research? Is there a particular component in the diagram you think I should try to build first?

Thanks in advance for any help, Juniperus

Anyone have recommendation for how I can scrap a website, and extract unique names -- such as product names.

I was thinking of using some website scrapping tool, then a local LLM to find unique product names.

I wrote a blog post about me getting in to FSharp web application development, but am having issues deciding how I want the data access to look. I'm very much open to feedback!

Crossposted from https://lemmy.ml/post/46897859

It is not my project.

I was looking for a lite version of Zed IDE without AI integrations, collab feature, telemetry etc and suddenly found it ^_^

I didn't test it excessively yet, but definitely give a try.

If you already tried it, please share your opinions.

cross-posted from: https://lemmy.ml/post/46884793

The Khronos OpenCL Working Group has released OpenCL 3.1, bringing widely deployed, field-proven capabilities into the core specification to expand functionality, including SPIR-V ingestion, that developers will be able to rely on across conformant implementations.

Features now mandated by OpenCL 3.1 have been deployed as extensions or optional capabilities. This is by design. The OpenCL working group evolves the specification by proving features in the field as extensions first, watching how they get used across multiple implementations, refining them based on developer feedback, and only then graduating them into the core specification.

Every conformant OpenCL 3.1 implementation will be required to consume SPIR-V kernels — a feature that has been one of the most requested by developers. OpenCL 3.1 additionally requires support for the SPIR-V query extension, which enables applications to enumerate the SPIR-V capabilities, extensions, and versions that a device supports, simplifying the adoption of new SPIR-V features as they become available.

Several features essential to HPC and AI kernels are also now mandatory in the core OpenCL 3.1 specification:

• Subgroups, including shuffles, rotations, and an expanded set of supported data types. A fundamental building block for tuned reductions, scans, and matrix kernels.
• Integer dot products, including saturating and accumulating variants, together with extended bit operations: Both map directly to dedicated hardware instructions on a wide range of modern silicon, and both are common building blocks for matrix multiplications and the low-precision arithmetic central to inference workloads.
• A new query for the suggested local work-group size. This gives applications and profilers a runtime hint for the optimal work-group size for a given kernel and device, eliminating the need for manual tuning or repeated size calculations across multiple enqueues and improving performance predictability on diverse hardware.
• A standard device UUID query, matching Vulkan’s VkPhysicalDeviceIDProperties::deviceUUID. This allows applications to correlate the same physical device across APIs, which is essential for multi-device systems and for external memory-sharing scenarios that span OpenCL and Vulkan.

The Cooley-Tukey fast Fourier transform can compute discrete Fourier transforms efficiently for signals of highly-composite length, such as powers of 2. However, to compute signal lengths with large prime factors, an algorithm such as Bluestein's is needed to prevent the algorithm from degenerating to quadratic complexity.

Thanks to Bluestein's algorithm, FFTs of prime-length input sequences are "only" ~4-6x slower than nearby powers of 2. The clunkiness of Bluestein's makes fast Fourier transforms interesting: the steps to complete the algorithm is not a monotonic function of the problem size, shooting up and down depending on the factors of the input length.

Interestingly, I found that almost no signal processing knowledge is required to understand and derive Bluestein's algorithm; anyone with general computing knowledge can follow along and should be able to implement Bluestein's algorithm after reading this post.

If this isn't the right community for this post, let me know and I'll move it somewhere else.

I'm working my way through nandgame, and I'm stuck on the "call" macro in the function calls section of the stack machine unit. These are the instructions:

I was stuck on it for a while, so I looked up the solution and am going off the one given here (it's the only one I could find).

So far, I haven't gotten it to work. At first, it was giving me syntax errors because the labels weren't defined, so I replaced A = [LABEL] with label [LABEL] followed by A = [CONST], according to the specified calling convention. It also gave me a similar syntax error for TEMP_ADDR, which is never specified in the instructions, so I assigned it 0x7f00. So here is what I end up with (all in Assembly):

(note: the stack pointer, SP, is defined by a shared constant SP = 0)

Test code:

init.stack
call functionName 0
stop

function FunctionName 0
push.value x42
return

Macro: call

# Assembler code
## Push the current ARGS and LOCALS on the stack
push.static ARGS
push.static LOCALS

## Push the return address.
push.value after

## Set ARGS to point to the start of the arguments
A = SP
D = *A
A = argumentCount
D = D - A
A = 3
D = D - A
label ARGS
A = 1
*A = D

## Jump to functionName.
goto functionName

## Set return address:
label after

## Restore ARGS and LOCALS from the stack
A = ARGS
D = *A
label TEMP_ADDR
A = 0x7f00
*A = D
pop.D
label LOCALS
A = 2
*A = D
pop.D
A = ARGS
*A = D

## Push RETVAL.
label RETVAL
A = 6
D = *A
push.D

Macro: function

# Assembler code
## Define a label functionName
label functionName

## Set LOCALS to the current SP
A = SP
D = *A
label LOCALS
A = 2
*A = D

## Advance SP by localsCount
A = localsCount
D = A
A = SP
D = D + *A
*A = D

Macro: return

# Assembler Code
## Pop the top value into RETVAL
pop.D
label RETVAL
A = 6
*A = D

## Set SP to LOCALS
label LOCALS
A = 2
D = *A
A = SP
*A = D

# Pop the return address and jump to it
pop.D
A = D
JMP

Note: functionName, argumentsCount, and localsCount are all listed as placeholders above the relevant macro, but it doesn't describe how to define these. I'm guessing that comes in a later unit. The code block for the call macro gives me a red bar for each line with a placeholder, but this doesn't happen for the function macro which also includes placeholders. In any case, this doesn't seem to get in the way of the program as it still runs smoothly.

So as it is, when I run it, everything seems to work as intended. This is the result when it reaches the stop macro (infinite loop):

Which looks like it's doing everything it's supposed to do. But when I click "Check solution", this is what it says:

("Expected SP (RAM address 0) to be hex 101. (Was 104)")

Which is strange, because in the computer section you can clearly see that the SP content is hex 0101. So I don't know what's going wrong.

I stepped through the program tick by tick, and the only place SP ever reaches 104 is after the function macro, when it runs push.value x42, after which it runs the return macro which begins with pop.D, reducing SP back to 103.

Could it be the evaluator is assessing the value of SP at the end of the code block, instead of where it runs the stop macro? So perhaps I could try replacing stop with a jump to the end, followed by stop... Now that I think of that, I think it might work. I'm still going to post this though, because I already went through all the trouble. And in case it doesn't work, if anyone else has any ideas please share them!

I can expand the rest of the macros if need be, but they already passed the evaluation so they're all working according to specs.

Thanks in advance!

Edit:

I thought for sure that would work. I changed the test code block to this:

init.stack
call functionName 0
A = end
JMP

function FunctionName 0
push.value x42
return
label end
stop

The program runs exactly as it's supposed to, except now the stop loop is at the end of the code. The computer output still looks the same, except now the program counter loops between 60 and 61 at the end (as expected). But the evaluator is still giving me the same error! I'm stumped...

Edit 2: added annotations to code blocks to make it easier to read