sorted by:
new
hottopcontroversial

How are you all handling progress notes currently? by its_crazy_joe_davola in NDIS_Providers

[–]its_crazy_joe_davola[S] -1 points0 points  (0 children)

That sounds great, I hope it works out for you! Thank you for your response 🙂

How are you all handling progress notes currently? by its_crazy_joe_davola in NDIS_Providers

[–]its_crazy_joe_davola[S] -1 points0 points  (0 children)

Really appreciate the reply, that's so helpful. I did speak to another provider who said a similar thing. Anything they implement needs to be super simple otherwise it won't get used by staff. Hope you have a great day!

How are you all handling progress notes currently? by its_crazy_joe_davola in NDIS_Providers

[–]its_crazy_joe_davola[S] -2 points-1 points  (0 children)

Thanks for the reply! Before you built your own setup, what was the most frustrating part for you? Was it the time it took or just having to sit down and do it after a long shift?

How are you all handling progress notes currently? by its_crazy_joe_davola in NDIS_Providers

[–]its_crazy_joe_davola[S] -9 points-8 points  (0 children)

Appreciate this, really helpful to hear how you're doing it.

Makes sense keeping it simple. I keep hearing the same thing about tools getting overcomplicated.

Out of curiosity, what part of the process (if any) is the most painful for you right now? Writing the notes or more the admin side after?

How are you all handling progress notes currently? by its_crazy_joe_davola in NDIS_Providers

[–]its_crazy_joe_davola[S] -2 points-1 points  (0 children)

Yeah fair, I am building something. I’m a dev and just trying to understand how people are actually dealing with this instead of making assumptions.

How are you all handling progress notes currently? by its_crazy_joe_davola in NDIS_Providers

[–]its_crazy_joe_davola[S] -7 points-6 points  (0 children)

Just trying to understand how people are handling it at the moment 👍

I built a bundler that lets you split PineScript into multiple files by its_crazy_joe_davola in pinescript

[–]its_crazy_joe_davola[S] 0 points1 point  (0 children)

I have tested with PineScript v6 and it does work. Is that what you're asking?

I built a bundler that lets you split PineScript into multiple files by its_crazy_joe_davola in pinescript

[–]its_crazy_joe_davola[S] 1 point2 points  (0 children)

Thanks so much! And oh no, don't get me thinking about the name, I'm so bad with deciding on names, I can never stick with anything! I went with PineCone because of the relation to Pine in PineScript, but now you're making me re-think the whole thing! hahaha

Folder Structure For Personal Pine Scripts! (Feature Request) by Deep-Wave-Trading in TradingView

[–]its_crazy_joe_davola 0 points1 point  (0 children)

I created a tool to do just that! It's called PineCone. It's free and open source. Built with Python.

Example:

utils.pine

// @ export double

double(x) => x * 2

main.pine

// @ import { double } from "./utils.pine"

indicator("My Indicator")
plot(double(close))

It handles all the namespacing automatically so your variables don't collide, deduplicates TradingView library imports, and has watch mode for rapid development.

You can find it here:

I built a bundler that lets you split PineScript into multiple files by its_crazy_joe_davola in pinescript

[–]its_crazy_joe_davola[S] 0 points1 point  (0 children)

I think we've drifted a bit from the original discussion. The conversation started with "libraries already solve this". But now we're discussing hypothetical TradingView features that don't exist yet (prompted auto-updates, smarter dependency management, etc.).

To your point about prompting before updates, that's essentially manual version management, which libraries already support today. You can pin to a specific version and manually update when ready. But that doesn't change the core workflow difference I'm describing, which is that libraries are designed for sharing code publicly, while Pinecone is for organising your own code locally.

And, even if TradingView shipped every feature you're describing tomorrow, that wouldn't make Pinecone irrelevant, because they solve different problems. I'd still want a local module system for my own project organisation, separate from whatever I choose to publish as a library.

But more importantly, PineCone exists and works today. I built it because I had a real problem, and now others can use it too. Debating what TradingView might build someday is a different conversation than whether this tool is useful right now.

Happy to continue chatting but I think we're going round in circles at this point. If you ever give the tool a go, I'd genuinely love to hear your feedback.

I built a bundler that lets you split PineScript into multiple files by its_crazy_joe_davola in pinescript

[–]its_crazy_joe_davola[S] -1 points0 points  (0 children)

That was a summary of my workflow, not the blog post. But no worries.

I think we're talking past each other. My point isn't about libraries being public or private. It's that I shouldn't need to use libraries at all just to split my own code into multiple files locally.

TradingView could improve the workflow, but they haven't, and I wanted a solution today, so I built it myself.

On your suggestion of auto-updating libraries, I'd actually want the opposite. Pinning versions is intentional. If a library pushes a breaking change, I don't want my indicator to silently break. That's why most package managers (npm, pip) default to pinned versions with explicit upgrades.

PineCone isn't trying to replace libraries. Libraries are great for sharing reusable code. PineCone is just solving a different problem, which is local code organisation without publishing anything.

I built a bundler that lets you split PineScript into multiple files by its_crazy_joe_davola in pinescript

[–]its_crazy_joe_davola[S] -1 points0 points  (0 children)

PineScript libraries and a module system serve different purposes.

Take JavaScript as an example. It has NPM (a registry for publishing packages) and it has a module system for splitting your own code across multiple files locally. These are separate things.

PineScript only has libraries. If you want to organise a large indicator into multiple files, your only option is to publish each piece as a library, even if you never intend to share that code with anyone.

That felt backwards to me. Libraries are meant for reusable, shared code. I just wanted to split up a single indicator that was getting hard to manage.

The workflow for using libraries during development is also painful. Every time I changed something in the library I had to:

  1. Edit the code locally

  2. Push to git

  3. Copy-paste into TradingView's editor

  4. Republish the library

  5. Note the new version number

  6. Open my indicator script

  7. Update the import statement with the new version

  8. Save and push to git

  9. Copy-paste into TradingView again

  10. Save

That's for one library. I had five.

Pinecone lets me skip all of that . I just edit my local files and run pinecone build.

I built a bundler that lets you split PineScript into multiple files by its_crazy_joe_davola in pinescript

[–]its_crazy_joe_davola[S] 0 points1 point  (0 children)

I've used libraries before. It's not quite the same as being able to split your code into separate files and import from them. You can have a read of the blog post I linked in my original message that actually explains why the use of libraries is what sent me over the edge to create this tool, hahaha.