SoylentNews

Canadian Liquor Stores Want You to Be Able to Buy Weed with Your Six Pack

Liquor stores in British Columbia and Ontario want to start selling weed once it becomes legal in Canada.

The two unions representing BC's public and private liquor stores announced a partnership this week—the Responsible Marijuana Retail Alliance of BC—through which they're advocating to sell recreational pot at retail locations by next Christmas.

Their logic seems to be that liquor stores already sell a controlled substance that gets people fucked up, so adding weed to their mix just makes sense.

"Just as with alcohol, there are legitimate concerns about access to marijuana by youths. Our stores are an over-19, age-controlled environment and our industry has demonstrated the strongest compliance with identification checks," said Stephanie Smith, president of the BC Government and Service Employees' Union, which represents the province's 200 public liquor stores.

It would also be cost effective. Because liquor stores already have a warehousing and retail system in place "there is no need to reinvent the wheel," she said.

Last month, Warren "Smokey" Thomas, head of the Ontario Public Service Employees Union, which represents LCBO employees, said LCBO outlets would be ideal weed retailers because they already have "social responsibility" covered.

"They do age checks, they do refusals if somebody's intoxicated."

[...]

This is a continuation of Perl 6 is way more Perl than Perl 5.

At some point I'll have to stop thinking of Roles and Traits as something I can do with Moose and start thinking of them as things that Perl 6 invented in the first place. That means Perl 6 isn't Moose on crack; Moose is Perl 6 sleep walking on Ambien. Moose did faithfully recreate the features and there are syntax differences between Moose and Perl 6 that matter little. However Moose has limited ways it can be implemented inside Perl 5 and so far Perl 6 gets this better.

I'm not quite sure how to explain what a role is for those who are unfamiliar with Modern Perl in any way. For reference the documentation for Perl 6 roles is at http://doc.perl6.org/language/objects#Roles and the Moose version is at http://search.cpan.org/~ether/Moose-2.1604/lib/Moose/Manual/Roles.pod but I'll try to do a quick summary here. Classes are concrete definitions of code and variables as in all models of OO I'm aware of. Roles also define code and variables but also can define interfaces/contracts by specifying things their implementation expects. Roles are applied to classes and the resources from the role are mixed into the class instead of coming in through an inheritance hierarchy. As roles are applied conflicts can be resolved manually through selective application of resources inside a role by the programmer or automatically by the language runtime. Because a role is mixed into a class the classes can still do all their normal class things including multiple inheritance if you really want it.

Another thing roles do is exist, have a name, and objects happily wear them like a badge of honor through meta-programming. Because roles define interfaces and objects let you know about their roles it is easy to find objects that implement the interfaces of a role if you know where to look for candidate objects. Because meta-programming lets you program the language from the language you can also apply roles at runtime at objects that never saw it comming. Because Perl 6 is highly regular everything is an object. Repeat: everything is an object.

Just how everything is an object is Perl 6? Instances of a class are objects, Classes are objects, Variables are objects, Attributes (class variables) are objects, Methods are objects, Functions are objects, and for all of those objects there are meta-objects that are objects that describe them. Unlike other languages there is no boxing of primative types so immediate values (or what ever a value is declared directly in source code is called) are objects too.

What does that even mean? You can apply a role to any of them! When applying a role to something like a function or attribute it typically changes the meta-objects in either subtle or drastic ways. For instance an attribute in a class is by default a mutable variable in private context but exposes an immutable variable through the public interface. Through application of a role to the attribute the meta-object is updated and the behavior is changed. That means Perl 6 uses roles for its own implementation; Perl 6 is extremely recursive like this and I think it is rather neat.

Traits are shortcuts for application of roles. Changing the mutability of an attribute in a class is done through the 'rw' trait while the 'ro' trait gets applied by default. For a class with one public scalar attribute it looks like this:

class Nope {
    #has declares a new attribute
    #$ defines the variable as being scalar (holds single thing)
    #. defines the attribute as being public
    has $.goodies;
}

class Yep {
    has $.goodies is rw;
}

my $ro = Nope.new;
my $rw = Yep.new;

$rw.goodies = "I drank your milkshake!";
say "Stored in rw: ", $rw.goodies;

$ro.goodies = "Little pig, Little pig, Let me in!";
say "Stored in ro: ", $ro.goodies;

And when executed gives the following output:

bash> perl6 journal.p6
Stored: I drank your milkshake!
Cannot modify an immutable Any
  in block <unit> at journal.p6:15

Roles and traits can be used by programmers to reduce the typing required by users of the interfaces that objects expose. In my proof of concept project described in Perl 6 is way more Perl than Perl 5 I'm looking for a way to mark object attributes and a method as being locations for storing input and output data and a way to perform operations on those pieces of data. There I used traits to apply roles to attributes and methods and update the meta-objects to provide methods for finding those attributes and methods. The exposed interface works out pretty well when creating a class that fits the model:

use v6;
#This brings in the Baller::Object role, supporting roles, and the
#inport, outport, and callpoint traits
use Baller::Object;

#does applies the Baller::Object role to the class
class Math::Add does Baller::Object {
    #The attributes have a type defined. A Cool is anything that can
    #act like a number or a string. They are like a Perl 5 scalar.
    has Cool $.arg1 is inport;
    has Cool $.arg2 is inport;
    has Cool $.result is outport;

    method calculate is callpoint {
        $!result = $.arg1 + $.arg2;
    }
}

Using the meta-object protocol it is easy to find the call point (or the ports) for an object:

my $thing = Math::Add.new(arg1 => 2, arg2 => 2);

say $thing.^methods.grep({ $_ ~~ Baller::Object::CallPoint });

Which provides a textual representation of a list of methods that do the role that is applied through the callpoint trait:

(calculate)

Working with the ports is easy too:

say $thing.^attributes.grep({ $_ ~~ Baller::Object::InPort });
(Cool $!arg1 Cool $!arg2)

say $thing.^attributes.grep({ $_ ~~ Baller::Object::Port });
(Cool $!arg1 Cool $!arg2 Cool $!result)

So is finding and invoking the callpoint method in object context:

#The array is typed and can only store objects that implement the CallPoint role
my Baller::Object::CallPoint @points = $thing.^methods.grep({ $_ ~~ Baller::Object::CallPoint });
#Because I don't really know what I'm doing yet
my $point = @points[0];

say "Output defined before invocation: ", $thing.result.defined;
#Invoke the discovered method in object context
$thing.$point;

say "Output defined after invocation: ", $thing.result.defined;
say $thing.arg1, " + ", $thing.arg2, " = ", $thing.result;

------

Output defined before invocation: False
Output defined after invocation: True
2 + 2 = 4

This exposed clean API is not with out cost though: the source code that implements the Baller::Object role has some cat barfing on a keyboard qualities.

use v6;

unit module Baller::Object;

use Baller::Node;

role Baller::Object::Port {

}

role Baller::Object::InPort does Baller::Object::Port {

}

role Baller::Object::OutPort does Baller::Object::Port {
    has Baller::Edge @.edges;
}

role Baller::Object::CallPoint {
    say "applying callpoint role";
}

role Baller::Object does Baller::Node {
    multi sub trait_mod:<is>(Attribute:D $attr, :$inport!) is export(:DEFAULT, :traits) {
        say "'inport' trait invoked: ", $attr.^name;
        say "args: ", $inport;
        say "args type: ", $inport.WHAT;

        $attr does Baller::Object::InPort;
        $attr.set_rw;
    }

    multi sub trait_mod:<is>(Attribute:D $attr, :$outport!) is export(:DEFAULT, :traits) {
        say "'outport' trait invoked: ", $attr.^name;
        say "args: ", $outport;

        $attr does Baller::Object::OutPort;
    }

    multi sub trait_mod:<is>(Routine $r, :$callpoint!) is export(:DEFAULT, :traits) {
        say "'callpoint' trait invoked: ", $r.^name;
        say "args: ", $callpoint;

        $r does Baller::Object::CallPoint;
    }

    #FIXME how can/should this be moved into a meta class?
    method inports {
        return self.^attributes.grep({ $_ ~~ Baller::Object::InPort });
    }

    method inport(Str $name is required) {
        my $attribute_name = "\$!$name";
        my @found = self.inports.grep({ .name eq $attribute_name });

        if (@found.elems != 1) {
            die "there must be only 1 result for '$name', got: ", @found;
        }

        return @found[0];
    }

    #FIXME how can/should this be moved into a meta class?
    method outports {
        return self.^attributes.grep({ $_ ~~ Baller::Object::OutPort });
    }

    method outport(Str $name is required) {
        my $attribute_name = "\$!$name";
        my @found = self.outports.grep({ .name eq $attribute_name });

        if (@found.elems != 1) {
            die "there must be only 1 result, got: ", @found;
        }

        return @found[0];
    }

    #FIXME how can/should this be moved into a meta class?
    method callpoint {
        my @points = self.^methods.grep({ $_ ~~ Baller::Object::CallPoint });
        if (@points.elems != 1) {
            die "only 1 entrypoint for an object is allowed; found: ", @points;
        }

        return @points[0];
    }
}

The benefit of Perl 6 is that I was able to put together enough end user API that it exposed an issue with my most fundamental and basic model that will be in use in my project. For all the good and bad this is pretty bad-ass.

I've been writing Perl 5 since 1995. I remember when Perl 6 was announced, I remember when Moose back ported the concepts from Perl 6 to Perl 5, and when Moo recreated Moose but allowed the Perl interpreter to start in less than a second. I can read Perl 5 that looks line noise though I very much dislike it. I spent my first 5 years writing Perl that was very much like garbage collected C then I picked up the more advanced features later. I tend to write clear and easy to understand code erroring on the side of being more verbose than necessary.

I've always kept a distant watch on Perl 6 while the development went through several implementations of the language. I started paying a little bit closer attention when Rakudo started shipping the Star releases. I started paying attention and hitting the documentation when rumor was spreading that a 1.0 release is near. I was elated when Larry Wall announced the majority of the work left to release Perl 6 1.0 is to fix the bugs people might mistake for features. Some time around Christmas 2015 the real Perl 6.0 will stand up.

The most recent release of the Perl 6 language is only a few months old and is pretty good. It is not completely polished but it certainly is letting me get a bunch of experimentation done. I just spent the day swimming around in attributes, Cools, accessors, Roles and partial documentation. At this point I've decided it is time to put some faith into Perl 6 and start using it so that in a few years when it is quite refined I'll already be seasoned at using it.

My thoughts after a solid day of doing something rather serious:

1. Oh my God if Perl 5 could be hard to read Perl 6 can be fucking impossible. Some of the examples look like a keyboard was left plugged into a computer while it was tossed into an industrial shreader. I think the ammount of ways that unreadable code could be implemented in Perl 6 is infinite. It looks like people are trying to prove that through brute force search.
2. "Perl makes hard things easy and impossible things hard" and Perl 6 scales the statement by an order of magnitude at least. I transformed my problem from having to generate a huge amount of code and glue data into hunting for the exact right way that Perl 6 provides the solution. The great thing is that I can learn the Perl 6 parts and stop having to hunt.
3. Perl 6 implements extremely good typing, better than any language I've seen before. You can work with anything from a 100% dynamically typed variable to an array made out of a contiguious chunk of RAM storing native floats or ints in 32 or 64 bit precision and operations on those arrays can be vectorized.
4. If you know Perl 5 think of Perl 6 as Moose, on crack, and faster, and the language is even more hackable from inside itself. Oh and grammars are something I don't fully grok yet but are obviously insane and powerful.

The project I'm working on is a proof of concept for implementing dataflow based computation. I really like dataflow and the application to event driven systems is very clean. I've never been particularly fond of any of the event handling frameworks and have tried a few times to create my own; never were the results very good or better than anything else available. Now I've got more experience under my belt though and I've decided to give it another shot while letting the language features of Perl 6 reduce my typing. This morning I started with some notes I've refined over the past few weeks:

Baller proof of concept: synchronous dataflow directed graph that adds numbers
from one source to a constant value and outputs the sum of both numbers to stdout.

       dataflow: Computation is performed through a network of objects that pass
                 data between each other. The program behavior is controlled through
                 the object types and their connections.

directed graph: Each object is represented as a node in a graph. Objects must have
                 at least 1 input or output for data but may have more than 1 of each.
                 The inputs and outputs of each object are called the object registers.
                 Edges connect output registers to input registers so there is always
                 a single direction that data travels between two nodes.

    synchronous: All objects in the graph must execute once, in data dependency order,
                 on each cycle of the graph. An object may only execute if the
                 input registers have defined values. The entry point for execution of
                 a graph for a single cycle is each node that has no connected input
                 registers (or no input registers at all) and each of those nodes must
                 be ready at the start of the cycle. As each node is executed the output
                 registers will be updated, values propagate to the input registers of
                 dependent nodes, those nodes become ready, and execution continues. If
                 execution of a single cycle can not happen because no more ready nodes
                 exist it is a fatal error unless the cycle has completed.

For an example of an existing real world system that uses a combination of graphical
modeling and dataflow based computation there is Scicos.

  * http://www.scicos.org/img/demos/SystemObserver.png
  * http://www.scicos.org/

  See Also
    * Kahn process networks
    * Petri nets
    * Flow-based programming

<graph mode="synchronous">
    <!-- SawStream has one output register named 'result' which on every
         cycle of the graph will have a single integer value that ranges from
         0 to 9 and wraps back to 0 again in a loop forever -->
    <node class="SawStream" id="stream"/>
    <!-- Math::Add is configured to have 2 numerical input registers named
         'arg1' and 'arg2' and a single output register named 'result' with
         the sum of both args; on each cycle the node performs the addition
         operation using the current values of the input registers. -->
    <node type="Math::Add" id="op">
        <conf inputs="2"/>
        <!-- define a constant value for input register number 2 -->
        <register name="arg2" constant="true">1</register>
    </node>
    <!-- STDOUT has a single input register named line and any data in there
         is sent as a string to stdout followed by a new line then the register
         is reset to empty again. If there is no data available in the input register
         the node will not be ready.
    <node type="STDOUT" id="display"/>

    <!-- the output of the SawStream node goes to one of the inputs of the math
         node; op.arg2 is a constant value and will be used every time the add operation
         is performed -->
    <edge in="stream.result" out="op.arg1"/>
    <!-- the output of the math block becomes the input of the STDOUT block
    <edge in="op.result" out="display.line">
</graph>

Executing the graph for 10 cycles would produce the following output:

1
2
3
4
5
6
7
8
9
10

  * The SawStream generated a sequence of values: 0 1 2 3 4 5 6 7 8 9

  * The math node adds the value of the SawStream output register for this current
    cycle to the constant value of 1 in the register named arg2.

  * The output of the math operation is then used by the STDOUT object to print the
    numerical value as a string.

And by the end of the day I had this code driving a minimal implementation of a dataflow engine:

use v6;

use Baller::Object;

class Math::Add does Baller::Object {
    has Cool $.arg1 is input[required => 1];
    has Cool $.arg2 is input[required => 1];
    has Cool $.result is output;

    method calculate is callpoint {
        $!result = $.arg1 + $.arg2;
    }
}

class StandardOut does Baller::Object {
    #Should the methods for implementation for the behavior go into the object in this variable
    #or should it go into the meta class? Inquiring minds have no idea what is a bad idea.
    #
    #The value in the register is reset on each cycle of this object and the value
    #must be defined for the object to be ready. The variable does not have to be defined
    #during construction though so is required does not appear to be correct.
    has Cool $.line is input[reset => 1];

    #can 'say' be imported from the perl6 implementation so the trait is the only required
    #part of the implementation?
    method say is callpoint {
        say $.line;
    }
}

class SawStream does Baller::Object {
    has Int $.current = 0;
    has Int $.result is output = 0;

    method next is callpoint {
        $!result = $.current;
        $!current++;

        if ($.current > 9) {
            $!current = 0;
        }
    }
}

say "Done with init. Doing stuffs.";
say "";

my $numbers = SawStream.new;
my $display = StandardOut.new;
my $op = Math::Add.new(arg2 => 1);

baller_connect($numbers, 'result', $op, 'arg1');
baller_connect($op, 'result', $display, 'line');

for 1.. 25 {
    baller_call($numbers);
    baller_call($op);
    baller_call($display);
}

sub baller_call(Baller::Object $obj) {
    if ($obj.inputs.grep({ ! .get_value($obj).defined })) {
        die "input register for $obj had empty value";
    }

    #FIXME feels like 'callpoint' belongs in the metaclass
    my $sub = $obj.callpoint;
    $obj.$sub();

    #FIXME feels like 'outputs' belongs in the metaclass
    for $obj.outputs -> $out {
        for $out.edges -> $edge {
            #say "$out -> $edge";
            $edge.propagate;
        }

        #FIXME set_value() has warnings against use, what is better?
        #$out.set_value($obj, Nil);
    }

    #$obj.inputs.map({ .set_value($obj, Nil) });

    return;
}

sub baller_connect(Baller::Object $out, Str $out_name, Baller::Object $in, Str $in_name) {
    my $out_attr = $out.output($out_name);
    my $in_attr = $in.input($in_name);

    push($out_attr.edges, Baller::Edge.new($out, $out_attr, $in, $in_attr));
}

It actually runs and outputs a saw toothed value from 1 to 10. I'm very much impressed with Perl 6.

This is part 0 of a series on Perl 6. The next entry is called Perl 6: Roles and Traits for President of the Universe

edit 1> Changed 1994 to 1995 - that's still 20 years worth of learning to think the way Perl does. I started on a 486 running Slackware distributed as a set of 10 floppy disks. At the same time I had a 386 sx laptop that took an entire night to compile the Linux kernel. I'm pretty sure I still had either MFM or RLL hard drives in service at that point because everything was shoe string. Setting up XFree86 needed some respect: it was still quite possible to ruin the CRT if the mode lines were wrong.

edit 2> Added link to next journal entry.

Lobbyists, in Strategy Session, Conclude That Refugee Crisis “Helps Us” Defeat Regulations

In an audio recording of a strategy session obtained by The Intercept, major trade association lobbyists discussed how the refugee crisis has changed the political dynamics in Washington to their advantage.

In the conference call held last week, lobbyists representing a number of high-polluting industries agreed that the battle between Congress and President Obama on refugee policy will give them the cover they need to attach a legislative rider to the omnibus budget bill that rolls back newly expanded clean water regulation.

“I think that probably helps us,” one participant said, referring to the coming confrontation over refugee policy.

[...] “We’re suddenly not the big issue,” said one call participant. “I mean, this is all going to turn on refugees.”

“I think that helps us,” said another call participant. “I think it helps us with the White House being on defense,” another legislative strategist on the call said.

The remarks were made during a political strategy call hosted last week by energy utility industry lobbyists. A recording was sent to The Intercept by someone on the call.

Coal CEO Thanks Lamar Smith, Asks Him to Expand Probe of Climate Scientists

Koch "Alliance" on Criminal Justice Reform Exposed as Trojan Horse

How the Gates Foundation Reflects the Good and the Bad of "Hacker Philanthropy"

What do guns and drones^Wquadcopters have in common? They both are a lot of fun and dangerous for people who are not involved in any way. I'm an avid R/C flight enthusiast and enjoy flying airplanes, traditional helicopters, and the modern quadcopter in many forms from gimbaled aerial video rig with video downlink, sport/stunt craft, and models so precision I can slalom them through the banisters in my staircase even though the flying machine fits in the palm of my hand. If I fly in public I'm respectful of others, generally don't want to be near anyone else not involved in flying, and I have liability insurance in case someone is accidently injured.

It really sucks when drone dolts wind up in the news because of some close call that happened or epicly bad idea they executed because the responsible R/C pilots get caught up in the mess because of guit by association. Unfortunately it is hard to argue with someone who is angry because their safety was threatened with someone elses careless act. Quadcopters falling out of the air isn't something the public should have to resonably worry about but the risks don't stop there. LiPo battery packs are a large safety hazard on their own because if they are punctured or shorted out they will get extremely hot and can catch themselves and other stuff on fire. Stabilized craft are also prone to "fly away" where the control system loses track of what direction gravity was pulling it, they pitch over sideways and start hauling ass in some random direction even though there is no input for that. If that happens who knows how far away it could fly - could be miles if you don't think to cut the throttle while you can still see it and control the crash to limit damage to property or people.

The FAA just formed a recommendation for registration of all remote control aircraft over 250 grams/9 ounces. The intent is sound: protect the public through education but I doubt this registration will have much effect. The Academy of Model Aeronautics, of which I am a member, believes that education of the public is the correct way to handle these safety problems and the impact on the image of R/C pilots as an entire community. To this end I propose a common sense set of rules to follow when flying your "drone"; they should keep you from hurting anyone else or winding up in front of a judge. Here are the Knowledge Troll Four Rules of Drone Safety:

1. All quadcopters are always dangerous.
2. Remove the throttle lock or arm the craft only immediately before takeoff.
3. Be sure of your airspace and what is under it.
4. Never point the camera of your quadcopter at something you are not prepared to defend yourself in court against.

The only problem is that people who care already think about these things. The 4 parallel rules for guns are also just too much for some people to grasp. Idiots aren't smart no mater how much information is provided to them. The ignorant can become educated and resolve the problem but an idiot lacks the part of their brain where learning happens. I would really hate to see the FAA continue to restrict access to the airspace for model craft and other small scale R/C devices used for non-commercial operation and I would much rather see them complete a comprehensive system where commercial access is available safely and with minimal total cost. I very much would let to get myself a commercial license instead of flying only under hobbyist rules.

PS> I typed drone so many times I almost threw up in my mouth.

PPS> Slashcode ate my previous journal entry on this topic and I think another persons journal too though I'd need a screen capture to be sure. This second iteration came out better anyway. Thanks slashcode, you are tops.

edit 1> s/(\^H)+/^W/g; #thanks AC claiming to be gewg_