Whatever happened to Laserweb?

CAD & CAM Tool Chain LaserWeb/CNCWeb
41

Well… here is a thing; over 2 years ago I added exactly the same fix I made yesterday to one of the two PR’s I have on my fork. Interesting; I have no memory whatsoever of fixing it the first time, but the change is bitwise identical. lol.

I’d like the changes from those PR’s in 4.1 if possible; but both need a small re-work, It was working on them and getting myself in a knot that originally caused me to stop development. Which is a shame because they are useful; especially the unordered operations one. It has a good use-case justification.

42

@easytarget I had come up with the identical fix for that in one of my 4.1 branch when I got going in the code earlier this year!

My recollection is a little hazy, but I may have pull requested the change and the PR might have disappeared when I changed my fork to target the mainline repo. That could be way off the mark though.

Not a git[hub] wizard, so I’m sure there’s an elegant way to do it, but I found I couldn’t have forks of both mainline and your 4.1 branch repo. I ended up forking mainline through github, then tracking your repo in a branch called I called easytarget-v4.1-dev.

I’ve got another small commit in there to fix the material db layout css, just changing ‘heading’ to ‘h5’ to make things happy again. Looks like I can PR it without too much fuss, if it’s of use.

Hope I didn’t butcher those terms too badly.

I’m getting my Fedora40 dev environment all sorted out right now and getting back up to speed.

2 Likes
43

I ended up making folders for the different accounts that make the projects. I have a Laserweb, easytarget and nathanielstenzel folder with different git clones in them. I am greedy and want copies of them all.

I actually used the easytarget clone as a test, wiped out and remade the whole environment as a test using a script I made to try to make sure that I had everything that I needed. I did however fail to test to the extent of uninstalling npm and nodejs and the packages that might be tied to them.

Sorry for disappearing for a bit. Political outcomes hit me hard sometimes and I also needed to spend some time with my mom who was also hit hard by political outcomes. I feel it would be wrong to go into further details here.

44

@NathanielStenzel No worries!

I’ve got a forked repo that I made since I’ve got a couple of small features that might not ever make it to mainline. The machine I built has a custom pen tool attachment for parts that need marking in addition to cutting, so the extra operation type with its own custom tool gcode makes LW the perfect program for my use case.

By adding and fetching the additional remotes it seems to mostly play nicely. I’ll admit I use the GitHub Desktop app and it helps my brain keep track of things a little better, but I hit occasional bumps that require hopping back into the terminal.

I wanted to ask you and @easytarget your opinions on using yarn instead of npm. When I set up my own repos and did the work on building the binaries, I found that yarn was giving better feedback around dependency issues. I still have more steps to retrace to get back to where I was, but I believe there were some good tools for tracking down unused dependencies and pruning the tree a bit.

I know a switch to yarn had been floated in the past but didn’t go anywhere. I just figured it was worth bringing up to see if either of you had any experience with or opinions on it. I certainly have no strong attachment to it, but if it could be of any benefit, it seems like it might be worth taking a look at.

45

Things of note from README.md:
@easytarget has a reference to a separate DOCKER.md

Things of note from package.js:
@malcolmmp has imports-loader, lw.comm-server, npm-run-all, react-hot-loader, script-loader, snap-svg, webrtc-adapter instead of webpack-merge in devDependencies.

dependencies section from @malcolmmp: bootstrap-range-input, dxf-parser, hoek, immutability-helper, object.omit, unicode, vectorize-text

dependencies section from my copy: bootstrap-range-input, dxf, json-stringify-safe, markdown-loader, object.omit, package.json, prop-types, script-loader, snapsvg-cjs, string-loader, webpack-cli

Of course, our scripts section is different. I simply made a simple change to make the environment setup a bit easier and @malcolmmp seems to have spent time to polish it. The copy from him seems to be set up to start either part of the software individually or all at the same time.

I tried to do the “npm run installdev” inside the folder of his fork and it crapped out on the node_modules/@serialport/bindings section and beyond. Some of this is gyp lines. There was a prebuild-install command call that was the first main thing to fail.

I tried copying over the document generation part from @malcolmmp 's package.js but it seems to add a requirement of jsdoc-toolkit. I do not know if we want that requirement or if there is a node package we could add to the dependency list or if we should skip it. It seems it also would involve his node_modules/ink-docstrap/template and jsdoc.json. I could not get that build environment to work for me so I could not proceed further investigation into the javascript documentation generation.

Since git has submodules and npm has the ability to include things via git, I am not sure which route is the best, but there is lw.machines, lw.materials in submodules, a number of things in npm git pulled dependencies and @malcolmmp has the lw.comm-server in the npm git pulled dependencies too.

46

Regarding yarn, I have zero experience. I noticed you have yarn files. I see the node-yarnpkg package on my Linux Mint system provides node-yarn. I would have to defer to you guys on that. I am basically a newb when it comes to the nodejs stuff. I did not touch it except back in previous Laserweb versions when I did some interface and gcode generation optimization. I never messed with the package.js before but there my main value is as a newb because the newbs will have to be able to get an environment up and running to be able to volunteer. So, there it is. Please just consider me the under-skilled nodejs newb and you guys make the decisions.

47

I’ll probably need until Sunday to dig into this; had to spend today away from computers. All the above items came from the upstream repo originally; I stripped broken NPM run targets and associated dependencies out of the package.json. they either didn’t work, or were so outdated they blocked other changes.

I also did a lot of webpack related work, upgrading it and fixing stuff up. This also caused some dependency changes.

The idea is to reduce maintenance complexity by choosing not to maintain every dev tool ever used. That’s why the react hot loader got removed. For instance.

having lw.comm.server in there was for developer convenience; it kind of assumed you have lw.comm.server published as a NPM package.

Possibly best to do a three way compare. Upstream, my fork and @malcolmmp 's fork.

Yarn would be nice; but AFTER we get 4.1 out please…

48

I hope the digging into the package.json that I did for a deep compare was useful. I think for my next trick I might move the package.json to the side and see what npm says for making a fresh one. How skinny will it be? That is something I am curious about.

49

Okay. My experiment had it with a ton more stuff in package.json and it did not compile. That was interesting but useless.

50

I tried again and got it to work with the scripts added back in and the questions answered and a little “npm install --force”, “npm init-dev”, “npm bundle-dev” (just for the sake of it?), “npm start-dev” (to pull up the page). The bloated size is probably due to the submodules which are not listed in the package.json. This experiment might be useful for anyone that sees my notes on it and needs to redo the package.json.

51

5 posts were split to a new topic: Laserweb dev offtopic, dealing with life

52

Thanks for the hint. I have removed the email-address of Anthony (but kept the kudos).

1 Like
53

Thanks! Corrected…

54

I can confirm that @easytarget s findings are correct. There are multiple different use cases like:

  1. Running lw.comm-server on Windows, macOS, Linux (+Pi) and call the integrated frontend via webbrowser (from the same or a different PC)
  2. Running the standalone app for Windows or macOS for local use.
  3. Running the standalone app to connect to a separate lw-comm-server or standalone App (locally or via LAN).

The standalone app (electron installer) is just for ease of use, but it’s the most frequently used one.

For now, I would not care about the standalone app. We should first concentrate on the client (frontend), to get it working with actual libs and make it maintainable (also for new devs). Then the server can be optimized/modularized for maintainability.

I can help with the server, but I can’t help much with the client. I was alllways questioning the use of react, because it’s too complicated for new devs (and was built for live multiuser frontends, not single user apps).

2 Likes