Cool little system prompt wrapper. Would be interesting to run this through some sort of benchmark/eval for identifying similarity
That sounds like a feature request.
Create an issue
Or don't, inwhich case it's a passive aggressive way of asking, where in duh uck are the tests?
Looks like an interesting project.
from gpt4all import GPT4All import argparse, sys, textwrap, subprocess, shutil
MODEL = "Mistral-7B-Instruct-v0.3.Q4_0.gguf"
local LLM
đźš®
Lie to someone else.
Only libre model ever published.
` And then import this project as an existing project into Eclipse (or clone and import directly within Eclipse if you have the Eclipse eGit plugin).
This is currently the only ready way to compile and run Anonymouth. We will be including a updated build file soon so that you may build and run Anonymouth easily within the command land, but sadly it hasn't been done yet so this is the only option currently `
What about for non-Java coders. I don't even use an IDE.
Anyway, packaging wise, you are alluding to a very real critical issue. The LLM is not packaged along with the Python code. It's just some stupid module level constant.
That was such an obvious noob mistake, didn't even bother mentioning it. It's the elephant in the room. Amongst a herd of other problems.
This along with the lack of, well just about everything, makes me wonder when it's time to pen an article and post it to this community.
I say this script falls well below that mark. Whatever that mark is.
The amateurishness is unfckingbelievable. This is the first time seeing a requirements.txt file and no pyproject.toml. What is that requirements.txt for exactly?
packaging is 80% of coding.
This includes: tests, dev environment (tox.ini, tox-test.ini, tox-req.ini, pre-commit, Makefile), full docs not just a README, gh workflows, stubs, pyproject.toml file ffs, static type checking with both mypy and pyright.
This is worse than strictyamlx which i actually would like to use, but come on! It's also terribly amateurish. What is with the partial typing signatures? Listen to Yoda, you either do or you don't, there is no try.
Everyone can be brilliant, everyone is brilliant, but packaging separates the little boys in their diapers from the men.
This author is sucking his thumbs in full view of the public.
If this project was a dart board, a blindfolded drunk could point out its shortcomings. Where to start?
Why even list the packages purpose and features, just beg/plead/grovel for help.
The pyproject.toml spec is ten years old. Python 3 is almost twenty years old. The community standard moved within the last five years. Tox is only necessary if you want to validate across specific versions so it can be replaced by tools like Poetry. If you’ve got GitHub workflows that’s the standard anyway so you should be running something like act locally. Static typing redundancy is a waste of compute.
If you’re going to be an asshole, make sure you can back everything up. You can’t so I’d recommend taking a breath and going outside.
Edit: I looked through your GitHub and even though your profile name is “msftcangoblowm” you don’t seem to use .yaml but instead the YAML extension Windows devs use.
Thank you for introducing me to act. First time seeing it.
Static typing redundancy is a waste of compute.
Have never encountered anyone suggesting doing less static type checking.
Static typing finds bugs. Especially pyright. Especially within tests. Separating the static type checking into stubs reduces any performance impact from typing related imports.
With py315, there will be soft|lazy import. Excess imports will have minimal impact cuz import proxy will be created but not executed until the import is actually used..
Tox is only necessary if you want to validate across specific versions so it can be replaced by tools like Poetry.
No it can't. They are two different things. tox can be replaced with nox. In the past, nox was promoted in this community. Looked into it and couldn't, for the life of me, figure out how it added value?
You mentioned Poetry, so i get to belittle Poetry. If you hadn't mentioned it, Would have keep my mouth shut. So this is on you!
Poetry only reason for being is to bring all the requirements files into TOML. The author loves TOML format. I get it. But at the expense of removing the constraint and requirement files hierarchy. Or a sane way of dealing with requirements of multiple venv. Or a sane clean way of managing dependency imposed lowerbound pins. Which come and go, so need to attribute which dependency imposed which set of lowerbound pins and most importantly why! Over time, the why is lost and with all the pins imposed by from various now unknown dependencies mixed into one insane pot.
Poetry is fine if you are the author of one package (and live in a utopia and not clownworld or fight club). And you have one venv. Lets scale that up to being the prolific author or maintainer of 10 or 100 inter-dependent packages each package having multiple venv. Now you are good and fck'ed cuz Poetry doesn't handle that situation. In fact, nothing does.
wreck tracks requirements by venv and syncs all the requirements as best it can. My intention was to eventually sync across multiple packages. But never got around to writing that level.
Poetry is unnecessary from the day the author first sat down to write it. And is the source of frustration to end users cuz Poetry encourages author/maintainers to create dependency upperbound pins.
So tell me again how wonderful Poetry is. Go on defend it!
First thank you for taking a look and holding my feet to the fire.
Have several packages based on strictyaml. What matters is YAML files are validated against a schema. Whether use .yml or .yaml is personal preference. My personal preference is typing less characters. Both should be allowed.
Share your hatred of Windows and don't even see it as a serious OS. So was actually surprised that .yml has some association with Windows or MSFT.
If while using any of below packages, you find the .yaml suffix is not recognized, that would be a bug. In which case, create an issue.
These published packages could be affected:
To actually confirm has bug status, would have to review the unit tests and see if .yaml is not tested nor recognized. Otherwise it's mere conjecture. It's an unconfirmed possibility. Maybe you are right, maybe not. Or maybe you are on to something.
The pyproject.toml spec is ten years old. Python 3 is almost twenty years old.
To my knowledge, for TOML spec, strict validating against a schema is not a thing. So it's not used with very likely dangerous user input.
So the spec could be 100,000 years old, for obvious security vulnerability reasons, would still not touch it.
Recommend taking a read through the strictyaml authors documentation on shortcomings of various user supplied input file formats.
You are in for a treat:
specifically Why not TOML
Relax, it's a python project. The entire language and tooling is a shitshow and it's famously terrible at packaging. If they wanted to write something serious they would use different language.