semvec/pypi-packages huggingface dataset:
spnoiser 1.1.2
Simple noiser: Run to annoy the user.
Requires Python: >=3.13

# spnoiser

Simple noiser: a tiny terminal alarm that repeats a message on the screen and can loop a short audio file (WAV recommended).

The package entry point is `spnoiser.app`. The main function accepts command-line arguments to control the displayed text, maximum duration, and an optional audio file to loop. If no audio file is provided, the program will attempt to use the terminal beep.

This project uses `src/main.py` as an alternative entrance, for debugging especially.

## Quick start

- Run directly from source:

```bash
uv run src/main.py -n "Beep" -t 120
```

- Install editable and run:

```bash
uv tool install -e .
spnoiser -n "Beep" -t 120
```

Note: the `spnoiser` console script is provided by the package entry point and is available after installation.

## Command-line arguments

The program (via `spnoiser.app:main`) supports the following options:

- `-n, --noise`  : Text to repeat on the terminal.
- `-t, --time`   : Maximum annoying time in seconds.
- `-s, --sound`  : Path to an audio file to loop. If omitted, the terminal beep is used when available.
- `-v, --volume` : Volume level for the sound file (>= 0.0). Default is 1.0.

Examples:

```bash

# Install first
uv tool install -e .

# Custom text and infinite duration, use terminal beep
spnoiser -n "Beep!" -t 0

# Loop a sound file to play instead of terminal beep
spnoiser -s "music/alarm.mp3"
```

## License

This project is licensed under the Apache License 2.0.

See the `LICENSE` file or the Apache website for the full license text: http://www.apache.org/licenses/LICENSE-2.0
moat-modbus 0.8.9
Modular async modbus client and server
Requires Python: >=3.8
Keywords: MoaT

###########
moat-modbus
###########

This is an anyio-enabled async frontend for pymodbus.

+++++
Usage
+++++

Check the example client and server for rudimentary usage.

Documentation patches gladly accepted.

++++++++++
Background
++++++++++

`moat-modbus` diverges from `pymodbus` in that it does not expose a "data
store" context to the user. Instead, every bus value is a separate object,
with arbitrary length and encapsulating its own encoding and decoding rules.

A Modbus server exposing writeable registers only needs to

* register the value in question

* wait for it to be written to

The rest happens behind the scenes.

+++++++++++++
Device Server
+++++++++++++

As some Modbus devices only allow ine server at a time, MoaT's Modbus
supports a simple bidirectional gateway.

How to get there:

* Write a generic device description. Put it in the modbus-data repository.

* Add an interface overlay that describes which topic to send the data to /
  which topic to read.

* Run ``moat modbus dev poll FILE.yaml``. You can use a generic systemd
  service if you copy the file to ``/etc/moat/modbus``.

The values can be modified (factor+offset); the gateway works in both
directions (command/state).

++++++++++++++++++++++++
MQTT / MoaT-KV interface
++++++++++++++++++++++++

MoaT-Modbus includes a server that's informed by a device profile. This server
acts as a bidirectional gateway from and to MQTT and/or MoaT-KV storage.

See "gateway.rst" for details.


TODO
++++

* configurable codecs
* get/set attributes
* pack multiple values into a message
* read-after-write if no slot
moat-lib-codec 0.4.8
A simple command/stream multiplexer
Requires Python: >=3.8
Keywords: MoaT

======================
The MoaT-Codec library
======================

This library packages various codecs used for MoaT protocols
in a way that's reason- and stream-able.

Interface
+++++++++

Codec
-----

* encode(obj)

  Encode the object to a bytestream.

* decode(bytes)

  Decode the given bytes to a single object.

* feed(bytes, final=False)

  Data stream. Returns an array of objects.

  This method only exists when a sequence of encoded objects can be streamed,
  i.e. contains built-in message boundaries.

  if @final is ``True``, raise an exception if there is an incomplete
  object in the buffer after this call.

* getstate(), setstate(\*args)

  A streaming decoder may store partially-decoded state (unprocessed
  buffer) here.

The list of accepted objects is implementation dependent.

Extension
---------

Extension types vary by whether they carry binary data as in (msgpack), or
objects (as in cbor).

* binary (classvar): True if msgpack-style, False if cbor-style

* encoder(cls, key, fn)

  Encode an object ``obj`` of type ``type``. ``fn(codec, obj)`` must return
  a bytestring / an encodeable object. If the registration key is ``None``
  the function must return a tuple with the key as first element.

* decoder(key, fn)

  Add a decoder (key, data) to an object. ``fn(codec, data)`` is called with a
  bytestring / a decoded object, and returns whatever has been encoded.

Extensions get the codec as their first argument. They can use it to store
data, e.g. references. The extension object is available as ``codec.ext``.
llama-index-packs-resume-screener 0.9.3
llama-index packs resume_screener integration
Requires Python: <4.0,>=3.9
Keywords: document, pdf, resume, structured output

# Resumer Screener Pack

This LlamaPack loads a resume file, and review it against a user specified job description and screening criteria.

## CLI Usage

You can download llamapacks directly using `llamaindex-cli`, which comes installed with the `llama-index` python package:

```bash
llamaindex-cli download-llamapack ResumeScreenerPack --download-dir ./resume_screener_pack
```

You can then inspect the files at `./resume_screener_pack` and use them as a template for your own project!

## Code Usage

You can download the pack to a `./resume_screener_pack` directory:

```python
from llama_index.core.llama_pack import download_llama_pack

# download and install dependencies
ResumeScreenerPack = download_llama_pack(
    "ResumeScreenerPack", "./resume_screener_pack"
)
```

From here, you can use the pack, or inspect and modify the pack in `./resume_screener_pack`.

Then, you can set up the pack like so:

```python
# create the pack
resume_screener = ResumeScreenerPack(
    job_description="<general job description>",
    criteria=["<job criterion>", "<another job criterion>"],
)
```

```python
response = resume_screener.run(resume_path="resume.pdf")
print(response.overall_decision)
```

The `response` will be a pydantic model with the following schema

```python
class CriteriaDecision(BaseModel):
    """The decision made based on a single criteria"""

    decision: Field(
        type=bool, description="The decision made based on the criteria"
    )
    reasoning: Field(type=str, description="The reasoning behind the decision")


class ResumeScreenerDecision(BaseModel):
    """The decision made by the resume screener"""

    criteria_decisions: Field(
        type=List[CriteriaDecision],
        description="The decisions made based on the criteria",
    )
    overall_reasoning: Field(
        type=str, description="The reasoning behind the overall decision"
    )
    overall_decision: Field(
        type=bool,
        description="The overall decision made based on the criteria",
    )
```