Programming Club

[Learning always]

Python also has semantic whitespace, which drives me bonkers. Fortunately since its the best-understood language by chatGPT, and since customGPTs run by business users like me can be given access to an integrated python code interpreter, allowing them to perform automated data analysis without having that data touch the much slower, more resource-constrained LLM, I doubt I’ll ever need to write a line of python again.

Javascript is less loathesome in my opinion but it has some problems to be sure. I myself like Ruby and would love it if duck typing wasn’t so brittle (the frequent need to coerce variables with .to_i or .to_s is indicative of a bad typing system - it would be better to either have the types be statically defined or purely dynamic).

Yes, but if you do systems programming, you won't need JS and Python.
Do you use C for systems programming?

 

[Learning always]

If we're to start a club project, what would you want to build ??

 

[The Liturgist]

Yes, but if you do systems programming, you won't need JS and Python.
Do you use C for systems programming?

For systems programming, primarily C with some use of D, which is a rather nice systems programming language that is underrated; Rust gets a lot of the attention I think D properly deserves (and before Rust stole D’s limelight, that attention was going to Go, a programming language written by Rob Pike’s group at Google, which is a good language, but among the people who tried getting into it when it was very much hyped up, it seems like most of them weren’t clever enough to take advantage of its unique features, which was also the case with the Plan 9 operating system and the conceptually related Inferno OS (which interestingly can run in a web browser as well as on bare metal, and which was intended for the Internet of Things before anyone knew what the Internet of Things was; for example, to justify its development to Bell Labs*, the Inferno developers suggested it could run on advanced desktop office phones allowing for a variety of sophisticated features, and such a phone running Inferno was sold; basically it was a landline smartphone (or technically, a wired smartphone - since IIRC it was not a PSTN phone but rather one that would either be behind a PBX or perhaps connected via some posh Centrex style service, perhaps using ISDN). Go at least has seen some use inside Google if memory serves. Also when doing actual development of embedded operating systems, which usually entails porting an existing open source operating system to a new device (although I do work with Wind River and QNX among other proprietary systems) there is often a need to work with assembler code for the platform, and when developing device drivers, sometimes one has to talk directly to the hardware in question (and since a lot of embedded real time OSes are by design, very simple, frequently they lack the facilities to help you do this that you get with a more fully featured OS like FreeBSD, NetBSD, OpenBSD, Linux, Illumos (formerly known as Solaris) or Microsoft Windows; indeed Windows has a highly developed driver framework which has become more restrictive because the massive crash that happened recently due to a buggy enterprise antivirus product, as documented in this article on ArsTechnica: Microsoft changes Windows in attempt to prevent next CrowdStrike-style catastrophe

Of course, with an embedded RTOS like eCos, there are fewer people trying to hack it, but given what such OSes are used for, security can be very high-stakes; indeed recall how the STUXNet OS was designed to infect Windows workstations in order to upload code to a Siemens industrial computer called a SCADA system that is used in many industries, but the code was specifically intended to change the RPMs in centrifuges being used by Iran’s nuclear project in such a way as to damage the centrifuges and slow down the project; many people regard the US-Israeli design to be the world’s first cyberweapon, but I rather doubt this; rather’ it was the first highly sophisticated attack of its sort which happened to be exposed, probably because getting it onto the computers in question involved, among other things, releasing the Windows malware component of it into the wild, which resulted in security professionals analyzing it and scrutinizing it and eventually the world learned of its true purpose.


*This was during an era when AT&T and then Lucent were increasingly demanding the research be aligned with immediate corporate objectives as the Labs continued their decline from an intellectual powerhouse like a combination of the RAND Corporation with MIT, a place where researchers could focus on research without needing to serve as professors. This decline is a shame, as it left the universities with a monopoly on that sort of innovation, and at its peak Bell Labs gave us much of the vital technology that enables our modern civilization, not just brilliant operating systems like UNIX or brilliant application software for various purposes, but transistors, and also many advances outside the field of telecom and computer science.

 

[The Liturgist]

If we're to start a club project, what would you want to build ??

Well, since you’re Catholic and I’m Orthodox, and a lot of members of the site are liturgical Christians, or are Christians who attend churches that use a lectionary such as the Revised Common Lectionary, I think a generic framework for managing the variable portions of worship services, ranging from appointed scripture lessons to the more sophisticated and elaborate propers of the Catholic, Orthodox and Lutheran liturgies (and also those of some Anglican churches and Ordinariate chruches which in addition to the Collect and the appointed scripture lessons, also use additional liturgical resources, some of which work with the Book of Common Prayer or the Book of Divine Worship, such as the 19th century classics Ritual Notes or the Directorum Anglicanorum, and some of which are used with the Anglican Missal, which is basically an English translation of the old Latin missal with some minor variations.

The key word here is generic - a basic building block type system which could be used by existing projects such as DivinumOfficium.com, CopticReader, the Liturgical Resources Department of the Malankara Orthodox Syrian Church, which currently has a primtive app that only displays PDFs, and the Ponomar Project which has done some automation (of these, divinumofficium.com probably has the most impressive tech, although lately they’ve also had a number of bugs, for example, the system failing to display the text of a mass on an arbitrary date in any format other than the basic low mass (so no text for a solemn mass for dates other than the present, for instance).

A basic text processing system built around managing variable text portions of a worship service, which could be changed in systems using the library either automatically based on the calendar date, or manually based on the preferences of the congregation or celebrant, since for example, the ordinary form of the Roman Missal provides four Eucharistic Prayers (plus a few additional ones for special purposes if I recall) and has several other variable portions, and the 1979 Episcopal Book of Common Prayer is the same (indeed, the 1979 BCP even followed the same sequence as the the Roman Missal in terms of the Eucharistic prayers, so the first one is the traditional Anglican Holy Communion service, the second one is, like the Roman Missal, based on the Anaphora of the Apostolic Tradition of St. Hippolytus, the third one is a variant of the Divine Liturgy of St. Basil, and the fourth one is Eucharistic Prayer no. 4 from the Roman Missal, which was intended for ecumenical celebrations of the liturgy); among more ancient liturgies, Coptic Orthodox liturgy allows for three Anaphoras (Eucharistic Prayers) to be used at the discretion of the celebrant and a large number of Fraction Prayers which are said while the priest breaks the bread, the Ethiopian Tewahedo Orthodox Church likewise provides a choice of around 14 Anaphoras, including one which is a complete, unabbreviated version of the Anaphora of the Apostolic Tradition of St. Hippolytus (documented in the third century by St. Hippolytus of Rome, but we know it was the ancient liturgy of Antioch, which later underwent revisions in wording, and the revised version is still used by the Syriac Orthodox and Maronite Catholics, but is also the basis for the Divine Liturgy of St. John Chrysostom, however, since the Ethiopians use the unrevised version and have done so since the fourth century, it is probably the oldest liturgical text in use in the world in substantially its original form); speaking of which the Syriac Orthodox Divine Liturgy has 86 Anaphoras of which decent English translations exist of around 16 of them.

Conversely, most Eastern Orthodox and Byzantine Rite Catholic (such as the Ukrainian Catholics, Ruthenian Greek Catholics, Melkite Catholics, Italo-Albanian Greek Catholics, the actual Greek Catholics of Greece, among many others) churches only use two Divine Liturgies, plus the Presanctified Liturgy, and when they use them is based on a highly prescriptive liturgical calendar which specifies absolutely everything such as the hymns to be sung at each service, what to do when two feasts such as a movable feast connected to the date of Easter and a fixed feast coincide, for example, if the Annunciation falls on the same day as Palm Sunday or even Pascha (Easter Sunday) - the latter event resulting in a particularly beautiful celebratory liturgy). There are other Eastern Orthodox and Byzantine Catholic anaphoras, such as the Divine Liturgy of St. James, which several Eastern Orthodox churches will celebrate this Thursday, the feast of St. James on the Revised Julian and Gregorian calendars, and the much less commonly used Divine Liturgy of St. Mark, a version of the ancient liturgy of Alexandria (which the Copts also celebrate) and the Divine Liturgy of St. Peter, which uses the Roman Canon, or Eucharistic Prayer 1 as its called in the Novus Ordo Missae.

Now all this complexity need not concern us, since what I propose is not an implementation but rather a toolkit designed to simplify the process of writing automated systems to handle all of the above. Indeed I have a complete set of specifications for this and was working on one before I fell ill; I’m a member of a group called LiturgyWorks which consists of various scholars, clergy and others interested in liturgies, and who have produced a number of texts which will be released into the public domain or in some cases under an open source license such as a creative commons license, but we made the decision to delay releasing them until we had an open source system which could allow for them to be used dynamically. I’ve been working on implementing that with AI, but got sidetracked with research into improving the AI system itself, for example, with biomimetic reproduction like I described above.

The difficulty level for the project is low, since its basically just a content management system adapted for handling liturgical texts, and using AI, we can make the development of it even easier by automating some of the more boring bits of code. What makes it interesting however would be in getting it to work ideally based on using an AI to generate the automation instructions from existing liturgical text books, by reading the rubrics, which would involve interfacing with an AI system (by making API calls to openAI or another provider, or alternately using an open source AI, which I would prefer - and interestingly, chatGPT will let you use it to develop training data for an open source special purpose AI such as one optimized to read rubrics and generate the appropriate text. Doing this using AI makes sense to me, because LLMs are the ultimate pattern-matching software; it’s like having a version of grep, sed, awk, m5, and all the other classic UNIX text processing tools, or equivalent tools some GNU, Linux and other developers use with GNU Emacs, but that one can converse with, in the English language or any number of other languages, even extinct languages such as Akkadian or Sumerian.

By the way my openAi Business account allows me to add people to my team which I would do for any serious contributor to this project, which would provide access to openAI’s Codex system for software development as well as the possibility of working on some of the advanced AI projects I have in mind. I’m presently already planning on adding a third seat to my account, since for various reasons I wound up using both of the two seats my business account requires as a minimum, and a third seat would allow me to let people who I’ve promised to allow see my AIs, such as my friend @Xeno.of.athens , access, and it could also be used periodically by people involved in this liturgical toolkit project.

 

[Xeno.of.athens]

you rang? ;-)

 

[Learning always]

Hello everyone. Would it be okay for me to join this club? Though I have not mastered a programming language, I desire to learn. Currently am reading a book on Python. I love to create things, so I find this all very interesting.

This story might be inspiring: Stories to Share - Friendship Court Edition

 

[Xeno.of.athens]

This story might be inspiring: Stories to Share - Friendship Court Edition

Here's something to look at, it is a python program (some people call them scripts) that Microsoft Copilot wrote for me
it will very likely be too advanced for you at this stage, but it may be useful as time goes by. self learning Python is not too hard if you use the python.org web site and its tutorials.

import hexchat

# Module metadata for HexChat plugin manager
__module_name__ = "SplitLongMessages"
__module_version__ = "1.0"
__module_description__ = "Splits long messages on word boundaries to fit IRC message size limits"

# IRC messages have a strict maximum length of 512 bytes, including metadata like sender and channel info.
# To stay well within this limit and avoid truncation or errors, we use a conservative content limit.
MAX_MESSAGE_LENGTH = 400  # This value can be adjusted for different IRC networks if needed.

def split_message(msg, max_len):
    """
    Splits a long message into smaller parts that each fit within the specified character limit.
    The split is done on word boundaries to avoid breaking words mid-way.

    Args:
        msg (str): The original message to be split.
        max_len (int): Maximum allowed length for each message part.

    Returns:
        list[str]: A list of message chunks, each within the safe length.
    """
    words = msg.split()  # Break the message into individual words
    parts = []           # List to hold the final message chunks
    current = ""         # Temporary string to build each chunk

    for word in words:
        # Check if adding the next word would exceed the limit
        if len(current) + len(word) + 1 <= max_len:
            # Add the word to the current chunk, with a space if needed
            current += (" " if current else "") + word
        else:
            # If the chunk is full, save it and start a new one
            if current:
                parts.append(current)
            current = word
    if current:
        parts.append(current)  # Add the final chunk

    return parts

def on_send(word, word_eol, userdata):
    """
    Hook function triggered when the user sends a message.
    If the message exceeds the safe length, it is split and sent in parts.

    Args:
        word (list[str]): The command and arguments as a list.
        word_eol (list[str]): The command and arguments as a list of full strings.
        userdata: Not used in this script.

    Returns:
        hexchat.EAT_NONE to allow the message through,
        hexchat.EAT_ALL to suppress the original and send split parts instead.
    """
    msg = word_eol[0]  # Full message text

    # If the message is short enough, let it pass through unchanged
    if len(msg) <= MAX_MESSAGE_LENGTH:
        return hexchat.EAT_NONE

    # Otherwise, split the message and send each part separately
    parts = split_message(msg, MAX_MESSAGE_LENGTH)
    for part in parts:
        hexchat.command("say {}".format(part))  # Send each chunk as a separate message

    return hexchat.EAT_ALL  # Prevent the original long message from being sent

# Register the hook to intercept all outgoing messages
hexchat.hook_command("", on_send)

# Print a confirmation message in the HexChat client when the script loads
hexchat.prnt("{} version {} loaded.".format(__module_name__, __module_version__))

 

[The Liturgist]

Here's something to look at, it is a python program (some people call them scripts) that Microsoft Copilot wrote for me
it will very likely be too advanced for you at this stage, but it may be useful as time goes by. self learning Python is not too hard if you use the python.org web site and its tutorials.

import hexchat

# Module metadata for HexChat plugin manager
__module_name__ = "SplitLongMessages"
__module_version__ = "1.0"
__module_description__ = "Splits long messages on word boundaries to fit IRC message size limits"

# IRC messages have a strict maximum length of 512 bytes, including metadata like sender and channel info.
# To stay well within this limit and avoid truncation or errors, we use a conservative content limit.
MAX_MESSAGE_LENGTH = 400  # This value can be adjusted for different IRC networks if needed.

def split_message(msg, max_len):
    """
    Splits a long message into smaller parts that each fit within the specified character limit.
    The split is done on word boundaries to avoid breaking words mid-way.

    Args:
        msg (str): The original message to be split.
        max_len (int): Maximum allowed length for each message part.

    Returns:
        list[str]: A list of message chunks, each within the safe length.
    """
    words = msg.split()  # Break the message into individual words
    parts = []           # List to hold the final message chunks
    current = ""         # Temporary string to build each chunk

    for word in words:
        # Check if adding the next word would exceed the limit
        if len(current) + len(word) + 1 <= max_len:
            # Add the word to the current chunk, with a space if needed
            current += (" " if current else "") + word
        else:
            # If the chunk is full, save it and start a new one
            if current:
                parts.append(current)
            current = word
    if current:
        parts.append(current)  # Add the final chunk

    return parts

def on_send(word, word_eol, userdata):
    """
    Hook function triggered when the user sends a message.
    If the message exceeds the safe length, it is split and sent in parts.

    Args:
        word (list[str]): The command and arguments as a list.
        word_eol (list[str]): The command and arguments as a list of full strings.
        userdata: Not used in this script.

    Returns:
        hexchat.EAT_NONE to allow the message through,
        hexchat.EAT_ALL to suppress the original and send split parts instead.
    """
    msg = word_eol[0]  # Full message text

    # If the message is short enough, let it pass through unchanged
    if len(msg) <= MAX_MESSAGE_LENGTH:
        return hexchat.EAT_NONE

    # Otherwise, split the message and send each part separately
    parts = split_message(msg, MAX_MESSAGE_LENGTH)
    for part in parts:
        hexchat.command("say {}".format(part))  # Send each chunk as a separate message

    return hexchat.EAT_ALL  # Prevent the original long message from being sent

# Register the hook to intercept all outgoing messages
hexchat.hook_command("", on_send)

# Print a confirmation message in the HexChat client when the script loads
hexchat.prnt("{} version {} loaded.".format(__module_name__, __module_version__))

It would be good to know which members are able to read that easily and who is not, because those who can are in a position to tackle more sophisticated projects.

By the way, my understanding is that MS is licensing parts of copilot from openAI.

Now, I myself find python extremely readable, especially compared to Perl scripts which have a tendency to self obfuscate, but aside from its problematic type system, I strongly prefer Ruby. Perhaps I just really like case statements (which we call switches in the more civilized world of C and its memory managed derivatives - the python alternative of a dispatch dictionary just isn’t pretty to me).

 

[Xeno.of.athens]

It would be good to know which members are able to read that easily and who is not, because those who can are in a position to tackle more sophisticated projects.

By the way, my understanding is that MS is licensing parts of copilot from openAI.

Now, I myself find python extremely readable, especially compared to Perl scripts which have a tendency to self obfuscate, but aside from its problematic type system, I strongly prefer Ruby. Perhaps I just really like case statements (which we call switches in the more civilized world of C and its memory managed derivatives - the python alternative of a dispatch dictionary just isn’t pretty to me).

a dispatch dictionary is a little "pythonic". But it makes sense

 

[The Liturgist]

a dispatch dictionary is a little "pythonic". But it makes sense

Indeed, like all Python. Although I would rather they had avoided the “elif” than the switch or case statement. A part of me would love to write some macros to generate python from a more sane language, which is possible, thanks to LLMs, but comversely, thanks to llms its no longer required, since an LLM, as I often like to say, is the ultimate expression of UNIX command line tools, and where I/O would become excessive, chatGPT can generate python code on the fly to “automate” its own work and then let thar do the work using the code interpreter subsystem without touching the slow AI part of the code (provided it can execute within a few minutes … anything more extensive than that and you can have it instead write code in an appropriate language to do the job for you).