Clojurians Log v2
calva
Ha!
Adding it to docs would probably be good. Doesn't hurt at least. :man-shrugging:
Totally agree.
Hi. I guess, this is more a Visual Studio Code issue in general. Does anyone have problems starting Calva/VSC? Yesterday everything was fine, today it fails coming up. Via Terminal I get:
> /usr/bin/code-oss --no-sandbox
/usr/lib/code/out/bootstrap.js:1
(function (exports, require, module, __filename, __dirname, process, global) { "use strict";(function(c,t){typeof exports=="object"?module.exports=t():c.MonacoBootstrap=t()})(this,function(){const c=typeof require=="function"?require("module"):void 0,t=typeof require=="function"?require("path"):void 0,u=typeof require=="function"?require("fs"):void 0;Error.stackTraceLimit=100,typeof process!="undefined"&&process.on("SIGPIPE",()=>{console.error(new Error("Unexpected SIGPIPE"))});function _(n){if(!t||!c||typeof process=="undefined"){console.warn("enableASARSupport() is only available in node.js environments");return}let e=n?t.join(n,"node_modules"):void 0;e?process.platform==="win32"&&(e=__dirname.substr(0,1)+e.substr(1)):e=t.join(__dirname,"../node_modules");const o=`${e}.asar`,r=c._resolveLookupPaths;c._resolveLookupPaths=function(p,a){const s=r(p,a);if(Array.isArray(s)){for(let i=0,l=s.length;i<l;i++)if(s[i]===e){s.splice(i,0,o);break}}return s}}function h(n,e){let o=n.repl
SyntaxError: Unexpected token function
at Object.exports.runInThisContext (vm.js:76:16)
at Module._compile (module.js:528:28)
at Object.Module._extensions..js (module.js:565:10)
at Module.load (module.js:473:32)
at tryModuleLoad (module.js:432:12)
at Function.Module._load (module.js:424:3)
at Module.require (module.js:483:17)
at require (internal/module.js:20:19)
at Object.<anonymous> (/usr/lib/code/out/cli.js:1:109)
at Module._compile (module.js:556:32)No idea about that. I’m guessing if it is fresh installs that no extensions are installed yet? Otherwise try with --disable-extensions.
For teh time being I installed the package from the website (not from repos). Tomorrow I'll give your idea a go.
Question about the current behavior of the results doc output file - currently calva uses the project root URI to decide where to create this file, what’s the advantage of doing this vs using a static location like the workspace root? A minor annoyance I’m regularly running into is having multiple output windows open up when I jack-in to a different project in the workspace. What would be the downside of making this output file directory static? Or, would it make sense if there was a calva setting that let you specify the output file path?
It is so that two projects opened from separate VS Code windows shall not write in the same file.
It’s not all that easy to have the same project open in two windows. Maybe a unique identifier would make sense, but it also makes sense to use the same file i that case, doesn’t it? Wouldn’t a unique file increase the annoyance with that we sometimes get multiple output windows?
There’s a handy command that lets you do it, I use it from time to time @command:workbench.action.duplicateWorkspaceInNewWindow
I was thinking the unique identifier could be bound to the window, some random ID created when calva starts up
I don’t think you’d want to use the same file across two windows if you are running separate REPLs. Ideally a single output file would be bound to a single REPL, and a single window should only ever show one output file. Now maybe if you are connected to the same REPL from two windows then it would make sense to output to the same file, but I’m not sure how easy it would be to do that while also ensuring there’s only a single output per window.
A problem is that VS Code does not have an API for dealing with the tabs.
Yeah I’m aware, it’s unfortunate there’s not a simple way to query the currently open tabs. That’s why I’m thinking picking a constant file name per-window would work well.
As long as we tread super carefully around the projectRoot logic/management, I am fine. It’s all too fragile. Also the name needs to make sense when displayed in the tab. If you experiment with this idea, consider autogenerating a .gitignore file that is placed in the .calva directory and that filters the range of possible names the file could get.
Sounds good, I’m going to take some time to play around with it this week and see what I come up with
Ok, I can see how this would cause in issue if two windows running two separate REPL processes would have a collision writing to the same file. But isn't that the case anyway of you have the same project open in 2 windows? If you wanted to prevent these collisions maybe the outout file name could have a unique identifier unique to the workspace?