Wow! I am truly humbled and indebted to all of you who took the time to help me out on my earlier questions. This was my first post here so I was a bit hesitant as I only joined a few weeks ago and wanted to ensure I did my homework before posting. Apologies if I was not able to respond to everyone’s replies but I feel that I must digest everything you’ve provided.

(I'm posting this here because I was getting embarrassed by how long my other thread was getting.)

I’m still a novice programmer and even more of an apprentice when it comes to Perl. Reading through the documentation, my head is starting to spin. My question originated because I was trying to come up with my own subroutine to determine permutations of elements in a array and I was getting lost in how to structure the subroutine using recursion (rest assured, questions on that topic are forthcoming!) But it appears to me that I still have more of the fundamentals to learn.

If I’m honest, some of the shine of Perl is starting to fade but the quality and quantity of help I have received here are motivating me to continue!

I don’t know and it doesn’t really matter. Some may ask why I ask. Because of by chance I «discovered» this. Very nice. See also FFI::Platypus.

  link: https://github.com/Baseband-processor/Air-Wireless
[download]

Recently I have released a new perl library: RTE::Dump

if anyone wants to test or contribute to the project let me know :P

Regards

Edoardo Mantovani, 2020

https://github.com/Baseband-processor/Air-Lorcon2

If interested in participating everyone can write an e-mail to: Baseband@cpan.org

Also suggestions, opinions and feedback are well accepted!

Thanks for every help from this site!

Edoardo Mantovani, 2020

There are streaming modules on CPAN that support gzip and Bzip2 and many more based on PerlIO::via, all using syntax like:

  # compress
  open  my $fh, ">:via(XXZ)", "test.xxz";
  print $fh $text;

  # decompress
  open  my $fh, "<:via(XXZ)", "test.xxz";
  while (<$fh>) {
      ...
      }
[download]

where XXZ is the required PerlIO::via::XXZ (gzip, Bzip2, ...) and .xxz is the extension that goes with it (.gz, .bz2, ...).

I needed this for xz-(de)compression, but it wasn't there (yet), so I stole from existing modules and whipped up PerlIO::via::xz, which works for what I want.

BUT, it fails in a scope where $/ = undef;, and I have no tuits to investigate.

This has not (yet) been put to CPAN, and to be honest, I don't feel like it (yet).

If anyone thinks this is a good thing to have and wants a kickstart in getting something ready to distribute, please contact me: you're welcome to grab it a use it to make it *your* (first) distribution.

Introduction

This is the follow up of Perl Automateaching -- part 1: brainstorming so read it first to have an idea of my intentions even if the pseudocode presented there is not what I currently plan.

I have choosen the name for this project and it will be Perl::Teacher as it is clear and explicative.

This post is a mere proof of concept about Perl teaching and, yes! it can be done! I'd like to be billionaire to hire super skilled perl geeks to develop my idea... but let's say they are all busy at the moment :) so the pupil (discipulus in Latin) will squeeze his brain and will dress teacher dresses. Contributors are welcome!

In the final form Perl::Teacher will be document oriented, ie: it will analyze perl programs wrote by the pupil in physical files. But in the current proof of concepts various student's attempts are hardcoded into the below program contained in scalars from $work_01 to $work_n and with a $solution_code

Also the final form of Perl::Teacher will be a bit interactive presenting and reviewing assignements and telling small lessons, but for the moment nothing of this is done.

So running the below program you will see a serie of attempts to satisfy the assignemnt and results of tests applied to provided code fragments.

Modify the $debug variable to 1 or 2 to see much more messages.

Proof of concept

Here my efforts up now (Ignore the warning you'll receive: Having more than one /x regexp modifier is deprecated at .../perl5.24-64b/perl/site/lib/Perl/Critic/Policy/ValuesAndExpressions/RequireInterpolationOfMetachars.pm line 110. beacuse it is a problem of Perl::Critic itself: see resolved issue on github)

Implementation (current)

As you can see there is a lot PPI stuff but not exclusively. Tests are execuded in order from 001 to 00n and if a test fails the current mini program is rejected.

Each test can contain different steps, the first one being the optional run that simply sends the current code to a sub: this preliminary, optional test passes if the sub returns 1 and fails otherwise. Here it is used only to check if the program compiles ( see below for future ideas ).

The second step of a test is select_child_of and it expects a PPI class name and a serie of subtests. Each PPI element of the specified PPI class, for example PPI::Statement::Variable (a variable declaration) will be processed to see if they contains PPI elemnts which satisfy all subtests. The first PPI element passing all subtests is returned by select_child_of and becomes a candidate for further inspections.

Infact if evaluate_to is also specified, the current PPI element is, take a deep breath, keep calm, string evaluated to see if it holds the wanted value. And hic sunt leones or here are dragons because eval only returns the last statement value. Search the code above for the string dirty trick to see my workaround. For me it is a genial solution, but wait, I'm the guy who string eval'ed entire CPAN.. :) so improvements are warmly welcome.

This form of testing is a proof of concepts: is not the final form of the testing framework needed by Perl::Teacher

When a miniprogram passes all tests it is evaluated by Perl::Critic to give more hints to the student. Eventual policy violations will not make the program to be marked as wrong, but are just presented as suggestions.

A note about flexibilty: looking carefully at the assignement you will notice that @letters and $result are constraints. Not the same for the intermediate scalars containing the first element and the last one.

Implementation (future)

module design

In my idea the course creator will publish Perl::Teacher::Course::EN::BasicVariables or Perl::Teacher::Course::IT::RegexIntroduzione all being child of the main Perl::Teacher::Course class. These courses have to be pluggable to the $teacher object ( Module::Pluggable probably but I have to investigate it further)

Each course will contain a serie of lessons published a sub modules, as in Perl::Teacher::Course::EN::BasicVariables::01_strings , ..::02_lists etc.

Yes I know: very long names.. but this will ensure a clarity of intent and of usage, in my opinion.

( update October 14 2020 see the related question Module design for loadable external modules containing data )

lessons

Each lesson will contain an ordered serie of optional elements: zero one or more assignement, multiple test elements possibly interleaved by one or more discourse and direct question.

So a possible flow can be:

Suggestions on module design are warmly welcome, but i want to keep it as simple as possible, not spawning objects for everything.

tests

Tests presented in the above code are too semplicistics to cover each teaching activity. I need beside positive tests also negative ones for example to prevent the use of modules, or all modules but one, to prevent external program execution and so on. Theese tests will be quite on success and will emit messages only on failure: "dont do this!".

I can use Test::Script to add tests about correct overall syntax check, behaviour of STDOUT and STDERR given different arguments and so on.

Then Perl::Teacher will provide its own tests like ones presented above: evaluate_to ( evaluate_at is probably a better name as it eval the code at a certain line), is dirty but it seems to me a viable option not so risky given the super small and controlled environment. I also plan a method named evaluate_subs which will grab al subs to test them.

I have to mix all this features in a clean and easy to use interface. Suggetions are welcome.

student interaction

During a lesson the student must have the possibility to review the current assignement, to receive hints and be pointed to relevant documentation. Part of this is roughly done in the presented code using hints and docs embedded in tests. Can be and must be improved.

I like to add a TIMTOWTDI discourse at the end of each lesson showing more ways to accomplish, even if not in the very same way, the assignement.

Every output, comprensive of examined code, errors and hints, emitted during 03_array_manipulation must be saved into a 03_array_manipulation.history file so that the student can review the whole lesson including errors commited and pitfalls and the solution alongside different approaches to the same problem. Passing the time this becomes a good source of knoweledge.

further ideas

Testing standalone scripts is an idea haunting me since years. Modulino is an approach. I can be mad enough to take the original PDOM of a given program, then save all subs and use PPI method prune to delete them from the PDOM, then wrap the rest into a new main_original_program sub, add it to a new PDOM along with all previously saved subs. Then I could do the obtained file and test it nicely. A lot of cut 'n paste and probably error prone, but can be a path to explore.

I'd like also my Perl::Teacher to be as much possible input/output agnostic: implement a way to interact with the console leaving open the possibility to be used by a web interface too: how to do this?

I'd like to ear your opinions about this project, sugesstions on module design and implementation of its parts, comments to the above proof concepts and everything you want to share.

L*

I've had a long ride of negativity over the past few years, and I haven't coped very well.

I want to thank all the Perlers (Monks and external). My life was saved.

My tears can't begin to describe appreciation I have for the outpouring of care you've shown, once again.

So today for the third episode of this diary, and after Diary of a Zydeco experiment - E02 - History, I would like to share a nice error message that I encountered while working on the modeling of my project. It can look strange to be happy about encountering an error message, but this one made my life really easier. It is still not about Zydeco directly but about one of the stable technology it relies on. Please don't look too deeply at the examples, they are mostly sarcastic but not very well structured on the OO side for now.

So we have this role, that summarize very naively what a Buyer can do:

    # lib/Wildlife/Behavior/Buyer.zydeco.pm
    role Buyer {
      requires money;
      method acquire ( Num $price ) {
        say "I bought !";
      }

      method sale ( Num $price ) {
        say "I sold !";
      }
    }
[download]

    # lib/Place/Behavior/Exhibit.zydeco.pm
    role Exhibit {
      has exhibition ( type => ArrayRef );
      has artist ( type => ArrayRef );
      has artwork ( type => ArrayRef )
      method display {
        say "Shoooow";
      }
    }
[download]

    # lib/Art.pm
    package Art {

      use Zydeco;

      class Place {
        has space;
        include Place::Behavior::Exhibit;
        include Wildlife::Behavior::Buyer;

        class Gallery with Exhibit, Buyer {
          has artwork (  type => ArrayRef );
          has artist (  type => ArrayRef );
          has event ( type => ArrayRef );
          has owner;
          has public;
        }
      }
    }
[download]

    # t/gallery.t
    use v5.16;
    use Test::More;
    use Art;

    my $gallery = Art->new_gallery(
      space => 1000,
      exhibitions => [ "Foo", "Bar" ],
      owner => "Arty Person",
      money => 10_000_000 );

    ok $gallery->does('Art::Exhibit'), 'Gallery does role Exhibit';
    ok $gallery->exhibitions, 'Gallery got an exhibitions attribute';
    ok $gallery->owner, 'Gallery got an owner';

    can_ok $gallery, 'acquire';
    can_ok $gallery, 'sale';
[download]

    smonff@padi:~/projects/Art-World$ prove -lv t/15_gallery.t
    t/15_gallery.t .. Can't apply Art::Buyer to Art::Gallery - missing
+ money at /home/smonff/perl5/perlbrew/perls/perl-5.32.0/lib/site_perl
+/5.32.0/Moo/Role.pm line 307.
    BEGIN failed--compilation aborted at (eval 269) line 1.
     at /home/smonff/perl5/perlbrew/perls/perl-5.32.0/lib/site_perl/5.
+32.0/B/Hooks/EndOfScope/XS.pm line 26.
    Compilation failed in require at t/15_gallery.t line 3.
    BEGIN failed--compilation aborted at t/15_gallery.t line 3.
    Dubious, test returned 2 (wstat 512, 0x200)
    No subtests run

    Test Summary Report
    -------------------
    t/15_gallery.t (Wstat: 512 Tests: 0 Failed: 0)
      Non-zero exit status: 2
      Parse errors: No plan found in TAP output
    Files=1, Tests=0,  2 wallclock secs ( 0.03 usr  0.00 sys +  2.00 c
+usr  0.10 csys =  2.13 CPU)
    Result: FAIL
[download]

The error message is launched by a croak call in the _check_requires() method of Role::Tiny.

    croak "Can't apply ${name} to ${to} - missing ".join(', ', @requir
+es_fail);
[download]

Once we add the right attribut to the Gallery class, everything goes well:

    class Gallery with Exhibit, Buyer {

      has artwork (  type => ArrayRef );
      has artist (  type => ArrayRef );
      has event ( type => ArrayRef );
      has owner;
      has public;
      has money;
      ...
  }
[download]

  smonff@padi:~/projects/Art-World$ prove -lv t/15_gallery.t
  t/15_gallery.t ..
  ok 1 - use Art;
  ok 2 - Gallery does role Exhibit
  ok 3 - Gallery got an exhibition attribute
  ok 4 - Gallery got an owner
  ok 5 - Art::Gallery->can('acquire')
  ok 6 - Art::Gallery->can('serve')
  ok 7 - Art::Gallery->can('sale')
  1..7
  ok
  All tests successful.
  Files=1, Tests=7,  2 wallclock secs ( 0.03 usr  0.00 sys +  2.30 cus
+r  0.16 csys =  2.49 CPU)
  Result: PASS
[download]

What I found amazing is how the error message makes sense. It just tells what should be done to fix the problem: adding a money attribute to the Gallery class. But more than that, it have a deeper meaning, that is exactly the point og this project. I mean you wouldn't have an art gallery with zero money would you? This is what I call efficient and reliable object oriented programming thanks Zydeco making a great use of the stable technologies it is built on (like Role::Tiny).

So far, my overall use of Zydeco is very satisfactory during the application modeling phase. Some could say that I could draw some class diagrams and not coding, but the Zydeco use is so easy and non-verbose that it really make possible to focus ont the modeling and not on the coding: focusing on listing attributes, methods, roles and their relationship, not on the implementation.

Next episode is mostly news from the brand new 2021 year...

So here is the history of what lead me to Diary of a Zydeco experiment - E01 - Introduction. This is a long term continuation of an art project started circa 2006.

In 2005, I got a metal box and colored carton cards and called this Le Fichier. It was basically a database of artworks ideas. I was trashing all ideas I could have of serious or weird potential artworks. It was inspired either by Roland Barthes, who was actually working with those kind of cards, Georges Perec, who was exploring potentialities, and Édouard Levé Oeuvres, a huge catalog of potential artworks (he later comited suicide after describing his own Suicide in a book).

2006 I initiated a FileMaker database of artworks to put the old style carton cards in computer form. I had no idea what I was doing at this time, being an art school student, at this time, programming was not massively taught as a fine art (unfortunately).

In 2008 I benefited of an artist residency in an agricultural college with a creation grant of 10 000€. I wanted to keep working on my Art World and Creative Processes schemas projects initiated during art school. It didn't go very well because the Plastic Arts State Inspector didn't like what I was doing with her money and strongly advised to change orientation. In my opinion, it was a perfect thing that the institution itself would exhibit it's own workings. In the end, there was an exhibition, but she didn't come to the opening.

Anyway, I ended up interviewing many Agents of the college, and went especially well with some natural sciences teacher. He recommended a manual were I found some schemas that I made some detournement: I used the geology science as a metaphor of art world. I used geology terms and language to describe social interactions that were not described in the art sociology field^{see illustration or see full presentation}.

The residency ended up with the redaction of a rather precise documentation (maybe my first specification).

Then I almost got beaten by a fellow artist who was participating in a collective exhibition mostly for the money and not for the fun. I guess he felt a bit provoked by my situationist theory.

In 2008, I finally decided to start a training to learn programming and design a proper database and system for managing a virtual Art World. I became a web developer, but I totally forgot the ulterior motive.

Sometimes I thought about it:

• 2013 Perl try - I bootstrapped a Perl module with 5 abstract empty classes and then let it sleep on Github
• 2017 Raku try - I restarted my project while trying to learn Raku (it was still Perl6 at this time), but learning Raku was too much effort and I abandoned again

Thirteen years after the initial idea I am still thinking about it. This project is following me in my dreams. I'll give it another try.

You'll tell me: this have nothing to do with OOP and Zydeco 🤔. Ok, we'll see this on Diary of a Zydeco experiment - E03 - Errors for fun and success.

Here is the first post of a small journal I want to keep about an experiment I will do with Zydeco. I hope the Perl Monks Meditations section is appropriate for this, if not, please feel free to redirect me on a better place (especially this is almost my first post here). I started to learn using Zydeco this week after suddenly getting abnormally excited about it. I guess Toby Inkster's marketing seemed to be very effective on me.

Where am I coming from? I was mainly trained on Java in 2009, so I am a object-native programmer. I mean, I cannot really imagine building something that wouldn't be made of objects, but also, Perl doesn't enforce object orientation, so you can still do without it. I don't know a lot about the how Perl's built-in OO works. I mostly used some modules:

• Moose - it is the de-facto OO module, recommended in lots of books and tutorials. I went into it when some systems I designed started to grow. You can do a lots of things with it, but it's difficult to use for prototyping for example
• Mojo::Base - It is usually not described as an independent OO system, but it provides attributes and accessors, readable source code, methods, roles (through Role::Tiny), method signatures. It is extremely simple to use even for prototyping, just use Mojo::Base. I got so used to it while working on Mojolicious projects that I usually import it even on non-web project!
• unfortunately, I don't think I ever tried Moo seriously

Next time I'll speak about the purpose of my experiment that is in fact an artistic project: trained as an artist, I accidentally became a professional web developer while trying to learn skills for my next conceptual art piece. But nothing went in the right way. Ten years afters, I am still working on it.