>If you are asking about the interface to add new problems to the system, there is no such interface.
I understand current SquarePerl.com features now.
I feel if a problem is added from web form, and answers are also added from web form, it will become interactive communication by a teacher and students.
Thank you for you suggestion! I'm sorry, but I'm not sure this is the text I'm looking for. For example the FooBar problem. There can be no errors in the output, but the system still does not accept solution because there are some differences between the PerlBanjo output and the expected output. I was trying to put it into short and and simple phase, but I failed. I have some ideas how to change interface to make it more clear, but I'm not sure when I will implement it.
]]>Oh, Thank you! I'm always very happy to hear that this small project is useful not only for me!
]]>I agree. Creating a file in some format on GitHub is not as user friendly as using a tool created exactly for that purpose. For this project I wanted that there is a way to change/add new problems from the very beginning. And as a cheap and easy solution I've used GitHub repo to allow edits.
We'll see what will happen in the future. If there is a demand for simple problem editing tool it is quite possible that I will create it. Or, maybe, somebody else will create some good tool to edit problem source code (for example it can be created as a VSCode plugin, or something like this)
It's a suggestion that p5p can go back to the mailing list conversation for big decisions.
I believe that big decisions should always be publicly and carefully discussed, even if some people disagree.
We can look for suggestions that are better for both sides.
If we can't find better way, the decision is something wrong.
Mpapec:
Certainly a single comparison using a padded number would be simpler.
Unfortunately the code has no control over the format of $version
because that value comes from an API. So using a single comparison with padded numbers would require extra logic to munge both values to pad them first. And I can’t think of any even remotely concise and simple way of doing that robustly.
Can you?
The best I can come up with is along the lines of
my @curr_ver = split /[.]/, $version;
my @len = map length, @curr_ver;
my ( $curr_padded, $min_padded ) = map sprintf(
'%0*d.%0*d.%0*d',
$len[0], $_->[0],
$len[1], $_->[1],
$len[2], $_->[2],
), \@curr_ver, [ 3, 6, 8 ];
my $version_ok = $curr_padded ge $min_padded;
(And even this is simplified vs a fully general solution, because it can rely on the fact that 3.6.8 has only a single digit in each component, so no component of $version
can be shorter than the corresponding component of 3.6.8.)
Now I don’t know about you, but… I’m afraid I’d take the <=>
version of the code any day over… that. In fact I’d prefer the original (with the chained duplicated numerical comparisons) over that.
sub vcmp0 {
my ($v1, $v2) = @_;
my @v1 = split /[.]/, $v1;
my @v2 = split /[.]/, $v2;
$v1[0] <=> $v2[0] || $v1[1] <=> $v2[1] || $v1[2] <=> $v2[2];
}
Sure it’s a bit copy-pasty but IMO that’s a benefit rather than a drawback in this case.
]]>I was wondering about this, though:
"At some point in the future, the PSC may decide that the set of features, taken together, represent a big enough step forward to justify a new baseline for Perl. If that happens, then the version will be bumped to 7.0."
Couldn't this be firmed up at this point? I would think the PSC has a set of features in mind that they'd like to see for Perl 7 (Corinna, etc). I can understand not wanting to over-promise but if you *can* say something about the next steps, it would be good to hear about it.
]]>use v7;
was the way to go, why not release Perl 7, as originally announced, just without it breaking v5 code? I.e. use v5.36;
should just be use v7;
- there's so many features there, including strict, signatures etc. Why wait more and seem less and less relevant to outsiders?]]>