Re: [elm-discuss] Re: elmvm (Elm Version Manager)

[Rehno Lindeque]

I'm a little surprised that more people haven't tried nix for pinning their 
Elm tools... E.g. pop a shell.nix file like this into your project root and 
you'll have it pinned to elm 0.18 indefinitely:

{
  bootpkgs ? (import  {}).pkgs
}:


let
  pkgs =
import
  (bootpkgs.fetchFromGitHub {
owner = "NixOS";
repo = "nixpkgs";
rev = "6018464c49dc60b1779f10a714974dcb4eb21c30";
sha256 = "1fq9zarsanislnsn9vrn4k852qk1ygckxqdzf1iywgsbp2a5hkn1";
  })
  {
overlays = [
  (self: super:
let
  inherit (self) fetchurl fetchFromGitHub callPackage haskell;
  nodeEnv = callPackage 
"${self.path}/pkgs/development/node-packages/node-env.nix" {};
in
{
  elmPackages = super.elmPackages // {
elm-reactor =
  haskell.lib.overrideCabal super.elmPackages.elm-reactor
(drv:
  {
# I'm using my own fork of elm-reactor that enables 
ports, because productivity
src = fetchFromGitHub
  {
owner = "rehno-lindeque";
repo = "elm-reactor";
sha256 = 
"0jfhg8gsy3r1myzls5ilx4i87d52lfr05l5736jxvjq926bfv3a2";
rev = "9a1887d60ec3753e25c10084c7ad25f566e5f0a8"
;
  };
  }
);
elm-format =
  haskell.lib.overrideCabal super.elmPackages.elm-format
(drv:
  {
src = fetchFromGitHub
  {
owner = "avh4";
repo = "elm-format";
sha256 = 
"0lman7h6wr75y90javcc4y1scvwgv125gqqaqvfrd5xrfmm43gg8";
rev = "e452ed9342620e7bb0bc822983b96411d57143ef"
;
  };


postInstall =
  ''
  ln -s $out/bin/elm-format-0.18 $out/bin/elm-format
  '';
  }
);
elm-oracle =
  nodeEnv.buildNodePackage {
name = "elm-oracle";
packageName = "elm-oracle";
version = "1.1.1";
src = fetchurl {
  url = 
"https://registry.npmjs.org/elm-oracle/-/elm-oracle-1.1.1.tgz";;
  sha1 = "61f6d783221b4ad08e7d101d678b9d5a67d3961c";
};
  };
  };
}
  )
];
  };
in
  pkgs.stdenv.mkDerivation
{
  name = "shell";
  version = "0.0.0";
  buildInputs =
( with pkgs.elmPackages;
  [
elm-make
elm-package
elm-repl
elm-reactor
elm-format
elm-oracle
  ]
);
}


As a bonus you can get to add extra goodies like elm-format, elm-oracle, 
your own personalized fork of elm-reactor or other non-elm tools perhaps 
(grunt, webpack, nodejs, etc...).

Just a thought anyway :)


On Thursday, April 6, 2017 at 4:30:02 PM UTC, Nicholas Hollon wrote:
>
> There needs to be a better advertising of the ecosystem both in terms of 
>> tools and in terms of packages.
>>
>
> I agree with this, but the effort needs to start with the library authors.
>
> As far as I can tell (searching this list, Google, & r/elm), Erik is the 
> only one of these authors who has publicized their work in any way.
>
> If you invent a wheel, you need to tell people about it. You can't just 
> leave it lying in your front yard and hope that people walk by your house 
> :-)
>
>
>
> On Thursday, April 6, 2017 at 6:34:53 AM UTC-7, Peter Damoc wrote:
>>
>> On Thu, Apr 6, 2017 at 3:43 PM, Eirik Sletteberg  
>> wrote:
>>
>>> None of these tools are mentioned in the Elm documentation. It only 
>>> points to installers and the npm module.
>>
>>
>> Exactly my point. 
>> There needs to be a better advertising of the ecosystem both in terms of 
>> tools and in terms of packages. 
>>
>>
>> -- 
>> There is NO FATE, we are the creators.
>> blog: http://damoc.ro/
>>
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: elmvm (Elm Version Manager)

[Rehno Lindeque]

> Looks very clever, not something I had ever looked into before. Do you 
> have to run NixOS or is nix something that you can run on top of any 
> distribution? (I'm a long time Debian user). 
>

Nix itself is just a cross-platform package manager, independent of the 
operating system NixOS. (Though, NixOS is pretty amazing by itself.)

https://ocharles.org.uk/blog/posts/2014-02-04-how-i-develop-with-nixos.html is 
one of the best known introductions I think (but note that Ollie wrote this 
in 2014). 
http://ebzzry.io/en/nix/#developmentenvironment might also be a good spot 
to start. 
 

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Comments on the TEA Components package

[Rehno Lindeque]

>
> *I have not seen the reverse happening.*


I usually try not to get involved in long threads like this nowadays, but I 
feel obligated to quickly mention that we were also recently pretty happy 
with a recent refactor that reduced the boilerplate in an internal 
documentation page. (We haven't published this as a package, we're still 
building some experience with it and mostly using the inverted control that 
folks generally recommend).

doc =
layout6
Symbol.component
Footprint.component
PackageOverlay.component
(SourceEditor.Form.component (SourceEditor.configure 
Example.sourceEditorConfig))
(PartEditor.Form.component Example.partEditorConfig)
ConsignEditor.Form.component
(\symbol footprint packageOverlay sourceEditor partEditor 
consignEditor ->
docBody []
[ div []
[ docSection "components"
"Components"
[ docSubSection "symbol" "Symbol" [ symbol ]
, docSubSection "footprint" "Footprint" [ footprint 
]
, docSubSection "packageoverlay" "PackageOverlay" [ 
packageOverlay ]
, docSubSection "sourceeditor" "SourceEditor" [ 
sourceEditor ]
, docSubSection "parteditor" "PartEditor" [ 
partEditor ]
, docSubSection "consigneditor" "ConsignEditor" [ 
consignEditor ]
]
]
]
)

main =
program
{ init =
doc.init
( force Example.symbol
, force Example.footprintFlags
, force Example.packageOverlayFlags
, force Example.sourceEditor
, force Example.partEditor
, {}
)
, subscriptions = doc.subscriptions
, update = doc.update
, view = doc.view
}

This was a fantastic reduction from the previous boilerplate and I'm really 
pretty happy with how it turned out (but I don't want to hold this 
particular example up as canonical, this is still an experimental approach 
with its own caveats, like any other architecture).

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Discovery: Model /= Database

[Rehno Lindeque]

Hi Kasey, I just wanted to mention that the wikipedia article 
Model-view-viewmodel 
 might 
be helpful reading. In some architectural patterns this is called the 
viewmodel rather than the model. (A couple of GUI oriented packages call 
this State, for the same reason I think).

At my workplace we tend to use the convention that models should be named 
after screen elements, e.g. PartEditor.Model whereas the response from the 
server would just be called Part (even though this record is closer to the 
database model).

-Editor, -Report, -Chart, -Table, -Matrix, -Page, -Viewer are of a couple 
of suffixes I'm tending to reach for when naming the modules that contain 
viewmodels.

On Saturday, April 22, 2017 at 7:18:41 PM UTC, Dustin Farris wrote:
>
> Interesting approach to just cache things in local storage and use the 
> Model as a view "state" only.
>
> I keep a nice store in my Model, but I think a key difference is that I'm 
> using websockets to update information automatically.  Each route (page) 
> has a list of channels that it cares about, and when data comes in on those 
> channels, the store is updated.
>
> WRT your issue on authenticated routes, my approach was to write a 
> function that checks the model for a Maybe String which is the JWT token. 
>  If it was Nothing, I'd send a Cmd to navigate to the login page.  It has 
> worked well so far.
>
>
> On Wednesday, April 19, 2017 at 7:28:06 PM UTC-4, Kasey Speakman wrote:
>>
>> I'm probably slow, but in recent months I've discovered that trying to 
>> use Elm's Model like a database or cache (as I have previously seen 
>> suggested) has turned out to be pretty painful for me. An example 
>> database-minded model where a section could display *either* a list of 
>> employees *or* a list of courses.
>>
>> type alias Model =
>> { employees : List Employee
>> , courses : List Course
>> , loadingError : Maybe Http.Error
>> , route : MyRoute -- employee or course
>> }
>>
>> The problem this runs into is having to worry about state management. I 
>> have to remember to "reset" or "turn off" things when they are not active. 
>> As my application grew, I had a lot of problems that boiled down to tedious 
>> state management details. My cached data didn't turn out to be all that 
>> useful because I usually had to reload it anyway, in case something changed.
>>
>> Instead, I have been moving toward the model only representing the 
>> current state of my UI. The big difference here is the model representing 
>> the current *visual* elements and their data. This leads more to using 
>> union types to represent parts of the UI. When you switch to a different 
>> case of the union type, the data from the previous case is *dropped on 
>> the floor*. This leaves nothing to remember to "reset". RemoteData is a 
>> good micro-example of this. If there was an error fetching the data, when 
>> the user requests the data again, you switch back to Loading, the error 
>> message is dropped on the floor. No forgetting to hide it.
>>
>> type RemoteData e a
>> = NotAsked
>> | Loading
>> | Failure e
>> | Success a
>>
>> If it is really important to cache the data, I prefer to keep that as a 
>> persistence concern, not on Model. It can be part of the process for 
>> retrieving the data to first check my chosen cache before making a request 
>> for fresh data. For instance, first check local storage before making an 
>> HTTP call. (Currently, this scenario is easier with Native modules for lack 
>> of Local Storage API or being able to wait on port subscriptions. But it's 
>> still doable.)
>>
>> So working towards a Model reflecting the visuals on the page has been an 
>> interesting challenge. I'm not claiming it's easier, but so far I've found 
>> it avoids a class of problems, and has led to some interesting discoveries 
>> in my own apps. One small example: I realized that my LoggedIn and 
>> NotLoggedIn routes should actually be separate "apps". Attempts to model 
>> this in a SPA fashion with the LoggedIn and NotLoggedIn routes as siblings 
>> always came up with the conundrum: how do I make it a compiler error for 
>> the model to be in LoggedIn mode but I receive a NotLoggedIn message, or 
>> vice versa? Even using TEA, I could not avoid this situation. Then I 
>> realized the only way to do that would be as separate apps. And that it was 
>> entirely possible to separate them. My "login page" turned out to be an 
>> entirely self-contained process: the user filling in info, obtaining a 
>> token, and saving it to local storage.
>>
>> I post this in the slim hope it is helpful to someone.
>>
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.googl

Re: [elm-discuss] Re: Moving on

[Rehno Lindeque]

> This grey list would be backed by a clear process of getting things on the 
> list that would include a checklist of mandatory things. 
> This checklist would be like a rule list and breaking any of the rule 
> would have to happen after a serious benefits analysis done under the 
> supervision of that experienced Elm programmers group I mentioned earlier. 
>

If this were the route people decide to take, I get the impression that 
this is the sort of thing elm-community does quite well. Perhaps a 
"greylist" could be simplified to https://github.com/elm-community/*. 

Something to keep in mind is that there's likely to be red tape required to 
fork a package on a special list. Not great if you need to fix something in 
a hurry and the author has disappeared. Elm-community provides a little bit 
of peace of mind for people like me who would like to make sure that 
packages they use have at least one active maintainer assigned to it and 
that the code has had some level of peer review.

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Moving on

[Rehno Lindeque]

Just to play devil's advocate for a moment; Despite my suggestion, and as 
much as I'm an advocate for package curation I don't think that it's the 
right first step towards solving the problem.

In my opinion the realistic solution is one that may already have been 
discussed in the past: 

1. Allow publishing any package, except prevent publishing packages that 
*depend* on packages that could cause run-time exceptions.
2. Issue a warning when you try to install a package with native code / 
effects.

Censoring packages indirectly based on dependencies sounds like a cop-out 
at first, which is why I think people haven't taken it seriously. But I 
think people haven't considered it as carefully as they should.

Breaking it down based how this affects each of the three concerns:

* Evan and other people with that take the "long-view" want to prevent 
run-time errors from becoming endemic to the ecosystem. No transitive 
dependencies means that run-time errors can be traced to a function call 
you made directly in your app.

* From a marketing perspective we don't want to water down the "no run-time 
errors" argument. Issuing a warning on installation provides some 
justification. Consider that clumsy JS interop negatively affects user 
acquisition and - perhaps more concerning - on user retention.

* Existing users and commercial users want to be productive. Being 
productive in the short term is as important as being productive in the 
long term when you have limited resources.

P.S. What attracted me to Elm was that it was being developed in a similar 
way to how a startup develops a product rather than how an academic might. 
However, I'm increasingly concerned that the current course that is set for 
Elm may be more dogmatic than it is pragmatic.

It worries a great deal that Elm's development methodology is based on 
early Python history. The world moves far more quickly than it did in the 
90's and I think it's dangerously complacent to imagine that we're still 
living in the same era. Consider that SourceForge was launched in 1999, 8 
years after Python first appeared. It's hard to hear but the world just 
doesn't work the same way anymore; people aren't working out of their 
basements in isolation (though they may be working out of their basement in 
a well managed team).

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Moving on

[Rehno Lindeque]

>
> First, I'm going to call out the air of ungratefulness and animosity in 
> this thread. Evan is giving you software for free, and it's software that's 
> good enough that you invest your time into writing it and commenting about 
> it.
>

Just to be clear, in case this is directed at me in part or as a whole. I 
forgot to mention that I highly respect Evan's work (in fact my company 
logo is on the front page of the elm website). This is important to mention 
whenever you offer any criticism, I apologize for not adding this 
counterweight to soften the blow. I forgot to consider how it might be 
taken. I wrote the postscript in a bit of a hurry and should have moderated 
down a bit I think. I generally try very hard to stay on point and fill my 
posts with information-dense arguments so that people will respond to the 
content rather than the tone.


To also add a bit of a positive spin to this, we've been making a push to 
make greater use of Elm at my work, so this is why I've become more 
interested in the health and sustainability of the ecosystem. We currently 
have a couple of internal screens in development that are 100% Elm. The 
experience has been pretty nice so far, though it took a little bit of time 
to aclimate to the Elm way. For a Haskell shop like ours it might have been 
more appropriate to use PureScript as it is better aligned with the skills 
we have in our team. However I think that Elm is a viable candidate and I 
sincerely hope that Evan will succeed in bringing it to the masses (and I 
think he should).


I'm hesitant, but perhaps just one meta-thought. I think that people here 
sometimes misattribute fear or even (misguided?) attempts at being helpful 
as animosity. I think a more moderated, and less reactionary approach to 
responding to people would also contribute to a less inflammatory 
environment and fewer of these meta discussions in general. Perhaps even 
just a friendly reminder quoted from the rules or something if you think it 
is appropriate.


My apologies for further increasing the length of this thread, seems like 
someone will need to start over with a concrete topic.

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Elm Textfield + a barcode scanner

[Rehno Lindeque]

In https://runelm.io/c/nx0 it looks like the trouble is that it is using 
value attribute no? Just to check, have you tried the defaultValue approach 
suggested? At least, in the example it doesn't look like value needs to be 
set at all.

My understanding is that two-way binding is problematic (there's some kind 
of race with the internal state of the control).

PS I think it would be interesting for someone to create a pure div control 
for text input some time (but that definitely way more challenging than it 
sounds).


-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.