Re: [elm-discuss] Immutable data design problem

[Lyle Kopnicky]

Thanks for your help, Aaron.

On Mon, Jul 24, 2017 at 11:01 PM, Aaron VonderHaar 
 wrote:

> Ah yes, a nice complicated system :)   If you're still looking for more
> abstract suggestions, here's how I would approach the problem:
>

Indeed the real system is much more complicated. This is a simulation
intended to help understand part of what's going on in the real system.
Eventually, we may actually incorporate it into the real system to help
users visualize relationships in California property tax.

It sounds like you're trying to construct intermediate data structures that
> directly map to certain domain concepts, and then you later have to
> transform that data into a structure that you ultimately need.  I suspect
> you may be able to clean it up a bit by focusing on what you need, and not
> on what you think you ought to have.
>

That sounds like a good approach. As of my last commit, I have it
representing AssessmentEvents and visualizing them. That involves some
rather simple calculations, the results of which are stored directly on the
AssessmentEvent object when it is created. I'm now trying to add Accounts
and visualize those, nested under the AssessmentEvents. But the
calculations to derive accounts are complex.

At the boundaries of the system, you have structured input data (perhaps
> being decoded from JSON?), possibly structured output data (perhaps being
> sent out as JSON?), and the UI view.  In my opinion, those are the most
> important types in your system.  Rather than trying to devise a data
> structure that's somewhere in the middle of the input and output, I'd focus
> on modeling the input and the output data structures in isolation, and then
> try to figure out the shortest/most modular route for transforming the data
> from one to the other.  If you work in this way, I think you'll tend to end
> up with more modular functions (which will also benefit you later, as you
> mentioned anticipating having to handle realtime updates to the data).
>

For now, it's not doing any kind of JSON import/export. It's being
initialized by sample data straight in the Main elm module. So perhaps it
would be premature to model that? But I do intend down the road to add JSON
import/export. There would be some script that extracts data from the real
system and produces the minimal form of JSON expected to import into the
visualization tool I'm developing. Another script could take the JSON
exports and use that to simulate objects in the DB. Since the data
displayed in my tool is a limited subset of read data, it will never be
used to try to serialize or create real data. The JSON exports could be
used to create test cases, though. My tool will be helpful in visualizing
edge cases.


> In what you're describing, the following things stuck out to me:
>
> > AssessmentEvents must in turn have been created by calling
> createAssessmentEvent, which takes the independent fields of an
> AssessmentEvent and creates the full record with the derived fields
>
> This sounds like it might be premature optimization.  If you didn't
> already try this, I'd suggest passing around the original raw fields
> instead and exposing the functions that can compute the derived fields.
> Furthermore, try having those functions take only the things that are
> needed for that exact calculation, rather than taking the entire
> AssessmentEvent record as an input parameter.  Doing this will help expose
> the actual dependencies in your data and avoid unnecessary coupling with
> the "AssessmentEvent" concept.
>

Hmm, sure, I could do that. But it would change the interface. Right now,
the view can simply deconstruct the AssessmentEvent to get any of the
originally supplied fields that it needs to render, such as eventDate, or
any of the calculated fields it needs, such as effectiveDate. So I would
have an inconsistent interface if it needed to call a function to derive
one but not the other. But I suppose you are suggesting that I hide the
representation entirely, so that a function has to be called in either
case. That would work. (I'm already doing that with some of the newer types
I've added, such as DateInterval.)

> when outside code needed to get the delta value, it couldn't just have an
> AssessmentEvent. It would have to have an AssessmentStore (or Parcel) and
> an EventID
>
> I would work backwards here and start with what data structure makes sense
> in the view, and then write the code to generate that from the raw data,
> and then see if there are logical groupings that make sense to refactor out
> as data types/modules (as opposed to starting with the domain concepts you
> think you are supposed to have and trying to write your view to work with
> those).
>

OK. The existing AssessmentEvent structure works for the view, of course,
since I already have that working. But I think you mean here not just
AssessmentEvents... but what is the full picture that the view needs of a
Parcel and all its 

Re: [elm-discuss] Immutable data design problem

[Lyle Kopnicky]

essmentEvents) can take the data in that private data structure and 
>> merge it together to give the data that you actually want to return to the 
>> caller.  In fact, you never need to expose the AccountIds/EventIds outside 
>> of this module.
>>
>> If you are still worried about safety, you can add more unit tests to 
>> this module, or try to define fuzz test properties to help you ensure that 
>> you handle the computations correctly within the module.
>>
>> I've found this sort of approach to work well because it lets you 
>> represent the data in whatever data structure is most performant and/or 
>> appropriate for your needs (it is often also simpler to implement because 
>> the data structures tend to be much flatter), but also hides the internal 
>> representation behind an module interface so that you can still access the 
>> data in whatever ways are most convenient for the calling code.
>>
>>
>>
>>
>> On Sun, Jul 23, 2017 at 7:16 PM, Lyle Kopnicky <lyle...@gmail.com 
>> > wrote:
>>
>>> I have a series of datatypes that have already been modeled in a 
>>> relational database in a product. I'm trying to construct a lighter-weight 
>>> in-memory representation in Elm for purposes of simulating operations and 
>>> visualizing the results. Ultimately I will probably want to do some 
>>> export/import operations that will allow someone to view data from the real 
>>> database, or create records in a test database. But, I don't think the 
>>> in-memory representations need to correspond exactly to the database ones 
>>> in order to do this. I'd like to focus on as simple of a representation as 
>>> possible, and I'm leaving out a fair number of fields.
>>>
>>> We start with a provided series of AssessmentEvents. It's just a limited 
>>> amount of data for each AssessmentEvent. Some of the fields in the database 
>>> can be calculated from the others, so those don't need to be provided. From 
>>> this data, we can calculate more information about the AssessmentEvents, 
>>> including deltas between them. We can also derive a series of Accounts in a 
>>> completely deterministic fashion. Each AssessmentEvent will have up to two 
>>> years associated with it, and for each year there will be at least one 
>>> Account. From this we can also calculate one or two Bills to go with each 
>>> Account.
>>>
>>> It's a fairly complex calculation. Certainly I can do it in Elm. But 
>>> what I'm waffling about is how to store the data. These calculations can be 
>>> cached - they do not need to be repeated if the user just changes their 
>>> view of the data. They only need to be revised if the user wants to 
>>> insert/edit/update AssessmentEvents. So to do all these calculations every 
>>> time the user shifts the view would be wasteful.
>>>
>>> It becomes tricky with immutable data. In an object-oriented program, I 
>>> would probably just have, say, extra empty fields on the AssessmentEvent 
>>> object, that I would fill in as I updated the object. E.g., it could have a 
>>> list of accounts, which initially would be a null value until I filled it 
>>> in.
>>>
>>> At first I thought I might do something similar in the Elm data 
>>> structure. An AssessmentEvent can contain a List of Accounts (I'm 
>>> oversimplifying as it really needs to list the accounts per year). The list 
>>> of Accounts can be initially empty. Then as I calculate the accounts, I can 
>>> create a new list of AssessmentEvents that have Accounts in the list. But 
>>> wait - since the list of AssessmentEvents is immutable, I can't change it. 
>>> I can only create a new one, and then, where in the model do I put it?
>>>
>>> When a user initializes the model, then, what should they pass in? 
>>> Perhaps they can pass in a list of AssessmentEvents that each have an empty 
>>> list of Accounts, and then that gets stored in a variable. Then the 
>>> Accounts are calculated, and we generate a new list of AssessmentEvents 
>>> with Accounts attached, and that is what gets stored in the model.
>>>
>>> But this has some shortcomings. The user must now create something that 
>>> has this extra unused field on it (and there will be more). I guess if they 
>>> are using a function to create it, they needn't know that there are these 
>>> extra fields. But what if the field isn't a list - it's an Int? Then do we 
>>> need to make it a Maybe Int? Then all the code that later operat

Re: [elm-discuss] Immutable data design problem

[Lyle Kopnicky]

tions suggested above (or any other function to get 
> AssessmentEvents) can take the data in that private data structure and 
> merge it together to give the data that you actually want to return to the 
> caller.  In fact, you never need to expose the AccountIds/EventIds outside 
> of this module.
>
> If you are still worried about safety, you can add more unit tests to this 
> module, or try to define fuzz test properties to help you ensure that you 
> handle the computations correctly within the module.
>
> I've found this sort of approach to work well because it lets you 
> represent the data in whatever data structure is most performant and/or 
> appropriate for your needs (it is often also simpler to implement because 
> the data structures tend to be much flatter), but also hides the internal 
> representation behind an module interface so that you can still access the 
> data in whatever ways are most convenient for the calling code.
>
>
>
>
> On Sun, Jul 23, 2017 at 7:16 PM, Lyle Kopnicky <lyle...@gmail.com 
> > wrote:
>
>> I have a series of datatypes that have already been modeled in a 
>> relational database in a product. I'm trying to construct a lighter-weight 
>> in-memory representation in Elm for purposes of simulating operations and 
>> visualizing the results. Ultimately I will probably want to do some 
>> export/import operations that will allow someone to view data from the real 
>> database, or create records in a test database. But, I don't think the 
>> in-memory representations need to correspond exactly to the database ones 
>> in order to do this. I'd like to focus on as simple of a representation as 
>> possible, and I'm leaving out a fair number of fields.
>>
>> We start with a provided series of AssessmentEvents. It's just a limited 
>> amount of data for each AssessmentEvent. Some of the fields in the database 
>> can be calculated from the others, so those don't need to be provided. From 
>> this data, we can calculate more information about the AssessmentEvents, 
>> including deltas between them. We can also derive a series of Accounts in a 
>> completely deterministic fashion. Each AssessmentEvent will have up to two 
>> years associated with it, and for each year there will be at least one 
>> Account. From this we can also calculate one or two Bills to go with each 
>> Account.
>>
>> It's a fairly complex calculation. Certainly I can do it in Elm. But what 
>> I'm waffling about is how to store the data. These calculations can be 
>> cached - they do not need to be repeated if the user just changes their 
>> view of the data. They only need to be revised if the user wants to 
>> insert/edit/update AssessmentEvents. So to do all these calculations every 
>> time the user shifts the view would be wasteful.
>>
>> It becomes tricky with immutable data. In an object-oriented program, I 
>> would probably just have, say, extra empty fields on the AssessmentEvent 
>> object, that I would fill in as I updated the object. E.g., it could have a 
>> list of accounts, which initially would be a null value until I filled it 
>> in.
>>
>> At first I thought I might do something similar in the Elm data 
>> structure. An AssessmentEvent can contain a List of Accounts (I'm 
>> oversimplifying as it really needs to list the accounts per year). The list 
>> of Accounts can be initially empty. Then as I calculate the accounts, I can 
>> create a new list of AssessmentEvents that have Accounts in the list. But 
>> wait - since the list of AssessmentEvents is immutable, I can't change it. 
>> I can only create a new one, and then, where in the model do I put it?
>>
>> When a user initializes the model, then, what should they pass in? 
>> Perhaps they can pass in a list of AssessmentEvents that each have an empty 
>> list of Accounts, and then that gets stored in a variable. Then the 
>> Accounts are calculated, and we generate a new list of AssessmentEvents 
>> with Accounts attached, and that is what gets stored in the model.
>>
>> But this has some shortcomings. The user must now create something that 
>> has this extra unused field on it (and there will be more). I guess if they 
>> are using a function to create it, they needn't know that there are these 
>> extra fields. But what if the field isn't a list - it's an Int? Then do we 
>> need to make it a Maybe Int? Then all the code that later operates on that 
>> Int will have to handle the case that the Maybe Int might be a Nothing, 
>> even though at that point I know it will always be Just something.
>>
>> Maybe there should be a dat

[elm-discuss] Immutable data design problem

[Lyle Kopnicky]

I have a series of datatypes that have already been modeled in a relational
database in a product. I'm trying to construct a lighter-weight in-memory
representation in Elm for purposes of simulating operations and visualizing
the results. Ultimately I will probably want to do some export/import
operations that will allow someone to view data from the real database, or
create records in a test database. But, I don't think the in-memory
representations need to correspond exactly to the database ones in order to
do this. I'd like to focus on as simple of a representation as possible,
and I'm leaving out a fair number of fields.

We start with a provided series of AssessmentEvents. It's just a limited
amount of data for each AssessmentEvent. Some of the fields in the database
can be calculated from the others, so those don't need to be provided. From
this data, we can calculate more information about the AssessmentEvents,
including deltas between them. We can also derive a series of Accounts in a
completely deterministic fashion. Each AssessmentEvent will have up to two
years associated with it, and for each year there will be at least one
Account. From this we can also calculate one or two Bills to go with each
Account.

It's a fairly complex calculation. Certainly I can do it in Elm. But what
I'm waffling about is how to store the data. These calculations can be
cached - they do not need to be repeated if the user just changes their
view of the data. They only need to be revised if the user wants to
insert/edit/update AssessmentEvents. So to do all these calculations every
time the user shifts the view would be wasteful.

It becomes tricky with immutable data. In an object-oriented program, I
would probably just have, say, extra empty fields on the AssessmentEvent
object, that I would fill in as I updated the object. E.g., it could have a
list of accounts, which initially would be a null value until I filled it
in.

At first I thought I might do something similar in the Elm data structure.
An AssessmentEvent can contain a List of Accounts (I'm oversimplifying as
it really needs to list the accounts per year). The list of Accounts can be
initially empty. Then as I calculate the accounts, I can create a new list
of AssessmentEvents that have Accounts in the list. But wait - since the
list of AssessmentEvents is immutable, I can't change it. I can only create
a new one, and then, where in the model do I put it?

When a user initializes the model, then, what should they pass in? Perhaps
they can pass in a list of AssessmentEvents that each have an empty list of
Accounts, and then that gets stored in a variable. Then the Accounts are
calculated, and we generate a new list of AssessmentEvents with Accounts
attached, and that is what gets stored in the model.

But this has some shortcomings. The user must now create something that has
this extra unused field on it (and there will be more). I guess if they are
using a function to create it, they needn't know that there are these extra
fields. But what if the field isn't a list - it's an Int? Then do we need
to make it a Maybe Int? Then all the code that later operates on that Int
will have to handle the case that the Maybe Int might be a Nothing, even
though at that point I know it will always be Just something.

Maybe there should be a data structure that contains an AssessmentEvent,
also containing the extra fields? But what if I have a series of functions,
each of which adds some new field to the AssessmentEvent? Then I need a new
data type for each step that just adds one more field?

Perhaps if I use untagged records, then all the functions can just operate
on the fields they care about, ignoring extra fields. I sort of liked the
extra type safety that came with the tagged record, but it may just get in
the way.

Perhaps instead of attaching this extra data to AssessmentEvents, it could
be kept in separate data structures? But then how do I know how they are
connected? Unless I carefully manage the data in parallel arrays, I will
need to add IDs to the AssessmentEvents, so they can be stored in a Dict.

These are just some of my thoughts. Does anyone have any suggested patterns
to follow?

Thanks,
Lyle

-- 
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: Detecting keypresses

[Lyle Kopnicky]

I was able to get both approaches to work:

1) Setting tabindex to 0 on the div: This works but the div does not
automatically get focus - I still have to click on it, and then it responds
to keypresses. I tried setting the attribute autofocus = 1 but that didn’t
help. Also it draws a blue border around the div, which I could probably
figure out how to hide.

2) Changing to a “program” instead of “beginnerProgram” and setting up a
subscription using the Keyboard package. I think I’m happiest with this.

In either case I’m now watching for keydown events.

On Fri, Feb 3, 2017 at 9:53 AM, Lyle Kopnicky <lylew...@gmail.com> wrote:

> I'll try that, thanks. I guess the elm-lang/keyboard approach is for
> catching keys from anywhere on the page, but catching them on the div is
> preferred if you have other elements on the screen that should manage their
> own keypresses. At this point it's the only div on the screen so it doesn't
> make a big difference. I'll try setting the focus and see how that works.
>
> On Thu, Feb 2, 2017 at 5:54 AM, Bernardo <auxs...@gmail.com> wrote:
>
>> Your code should work with a couple of changes. To receive the events the
>> div should have the focus; divs normally don't have focus, so you need to
>> add the attribute tabindex 0 to be able to focus the div. Also instead
>> of the keypress event you should listen to keydown as keypress is only
>> for printable characters.
>>
>>
>> On Thursday, 2 February 2017 04:23:31 UTC-3, Lyle Kopnicky wrote:
>>>
>>> Hi folks,
>>>
>>> I'm having trouble detecting keypresses in Elm 0.18. The only examples I
>>> can find are old ones that use Signals. There are no examples in the Elm
>>> Architecture Tutorial. The Html.Events module documentation shows a piece
>>> of the puzzle with the example for onKeyUp.
>>>
>>> Heres a gist with the code: https://gist.github.com/
>>> anonymous/5f54c2b2c8fb42a31d4ae37058a72e2a
>>>
>>> You can ignore the KaTeX import - that's not used at the moment.
>>>
>>> It compiles and runs, but the circle just sits there. I have know way of
>>> knowing if it's detecting my keypresses. I thought that by putting the
>>> event handler on the outer div, it would intercept keypresses. I didn't
>>> have any way of adding handler to the svg element.
>>>
>>> BTW I also tried 'keyup' instead of 'keypress', and I tried making it
>>> generate the MoveRight message for any key, just to make sure it wasn't bad
>>> key code problem.
>>>
>>> Do I need to somehow attach the keypress handler to the document
>>> instead? Perhaps I need to use a subscription? I'm not finding any guidance
>>> in the docs. Any help would be appreciated.
>>>
>>> Thanks,
>>> Lyle
>>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Elm Discuss" group.
>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>> pic/elm-discuss/TytivlR2CH0/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> elm-discuss+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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: Detecting keypresses

[Lyle Kopnicky]

I'll try that, thanks. I guess the elm-lang/keyboard approach is for
catching keys from anywhere on the page, but catching them on the div is
preferred if you have other elements on the screen that should manage their
own keypresses. At this point it's the only div on the screen so it doesn't
make a big difference. I'll try setting the focus and see how that works.

On Thu, Feb 2, 2017 at 5:54 AM, Bernardo <auxs...@gmail.com> wrote:

> Your code should work with a couple of changes. To receive the events the
> div should have the focus; divs normally don't have focus, so you need to
> add the attribute tabindex 0 to be able to focus the div. Also instead of
> the keypress event you should listen to keydown as keypress is only for
> printable characters.
>
>
> On Thursday, 2 February 2017 04:23:31 UTC-3, Lyle Kopnicky wrote:
>>
>> Hi folks,
>>
>> I'm having trouble detecting keypresses in Elm 0.18. The only examples I
>> can find are old ones that use Signals. There are no examples in the Elm
>> Architecture Tutorial. The Html.Events module documentation shows a piece
>> of the puzzle with the example for onKeyUp.
>>
>> Heres a gist with the code: https://gist.github.com/
>> anonymous/5f54c2b2c8fb42a31d4ae37058a72e2a
>>
>> You can ignore the KaTeX import - that's not used at the moment.
>>
>> It compiles and runs, but the circle just sits there. I have know way of
>> knowing if it's detecting my keypresses. I thought that by putting the
>> event handler on the outer div, it would intercept keypresses. I didn't
>> have any way of adding handler to the svg element.
>>
>> BTW I also tried 'keyup' instead of 'keypress', and I tried making it
>> generate the MoveRight message for any key, just to make sure it wasn't bad
>> key code problem.
>>
>> Do I need to somehow attach the keypress handler to the document instead?
>> Perhaps I need to use a subscription? I'm not finding any guidance in the
>> docs. Any help would be appreciated.
>>
>> Thanks,
>> Lyle
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/elm-discuss/TytivlR2CH0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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: Detecting keypresses

[Lyle Kopnicky]

Looks like there's a community package elm-lang/keyboard: 
http://package.elm-lang.org/packages/elm-lang/keyboard/latest

I'll give that a try.

On Wednesday, February 1, 2017 at 11:23:31 PM UTC-8, Lyle Kopnicky wrote:
>
> Hi folks,
>
> I'm having trouble detecting keypresses in Elm 0.18. The only examples I 
> can find are old ones that use Signals. There are no examples in the Elm 
> Architecture Tutorial. The Html.Events module documentation shows a piece 
> of the puzzle with the example for onKeyUp.
>
> Heres a gist with the code: 
> https://gist.github.com/anonymous/5f54c2b2c8fb42a31d4ae37058a72e2a
>
> You can ignore the KaTeX import - that's not used at the moment.
>
> It compiles and runs, but the circle just sits there. I have know way of 
> knowing if it's detecting my keypresses. I thought that by putting the 
> event handler on the outer div, it would intercept keypresses. I didn't 
> have any way of adding handler to the svg element.
>
> BTW I also tried 'keyup' instead of 'keypress', and I tried making it 
> generate the MoveRight message for any key, just to make sure it wasn't bad 
> key code problem.
>
> Do I need to somehow attach the keypress handler to the document instead? 
> Perhaps I need to use a subscription? I'm not finding any guidance in the 
> docs. Any help would be appreciated.
>
> Thanks,
> Lyle
>

-- 
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] Detecting keypresses

[Lyle Kopnicky]

Hi folks,

I'm having trouble detecting keypresses in Elm 0.18. The only examples I
can find are old ones that use Signals. There are no examples in the Elm
Architecture Tutorial. The Html.Events module documentation shows a piece
of the puzzle with the example for onKeyUp.

Heres a gist with the code:
https://gist.github.com/anonymous/5f54c2b2c8fb42a31d4ae37058a72e2a

You can ignore the KaTeX import - that's not used at the moment.

It compiles and runs, but the circle just sits there. I have know way of
knowing if it's detecting my keypresses. I thought that by putting the
event handler on the outer div, it would intercept keypresses. I didn't
have any way of adding handler to the svg element.

BTW I also tried 'keyup' instead of 'keypress', and I tried making it
generate the MoveRight message for any key, just to make sure it wasn't bad
key code problem.

Do I need to somehow attach the keypress handler to the document instead?
Perhaps I need to use a subscription? I'm not finding any guidance in the
docs. Any help would be appreciated.

Thanks,
Lyle

-- 
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] Local third-party packages

[Lyle Kopnicky]

That worked great, thanks!

I used elm-github-install to install the bsouthga/elm-katex package
directly from GitHub. I didn't have to rename my own local project. I only
need to fork bsouthga's project if I want to update it to use a newer
version of KaTeX.

I didn't want to install gems in my global system dir as root, so I
installed rvm and the latest version of Ruby. Then I did gem install
elm_install.

Unlike elm-package where you can specify a package name and it will
automatically update your elm-package.json, I had to manually add an entry
each to dependencies and dependency-sources, then run elm-install. Then I
was able to build my project with no problem, and everything worked.


On Sun, Jan 29, 2017 at 11:23 PM, Peter Damoc <pda...@gmail.com> wrote:

>
>
> On Mon, Jan 30, 2017 at 8:48 AM, Lyle Kopnicky <lylew...@gmail.com> wrote:
>
>> So I wonder if I can use elm-package to install a package from another
>> directory, so hopefully the references will work out right?
>>
>
> elm-package does not support that BUT, elm-github-install
> <https://github.com/gdotdesign/elm-github-install> was designed for such
> contexts.
> Add the package manually to your dependencies and then use
> elm-github-install to install it.
>
>
>> when I build my project, because I'm using the default project URL, it
>> gets referenced as _user$project$Native_KaTeX, which doesn't match.
>
>
> You need a valid github project. Default values don't work. So, if you
> fork the project and replace the user in that Native function name, you
> should be able to compile it just fine.
>
>
>> Another possibility is given by looking at https://github.com/eeue56/t
>> ake-home/wiki/Writing-your-first-Elm-Native-module. Here the author
>> shows some very different boilerplate, which doesn't seem to involve the
>> project name in the variable names. I'd have to copy the elm-katex code
>> into my own project and tweak it a bit, but that's OK for now as I'll only
>> be building/running my project locally for the foreseeable future. Also I'd
>> be able to update the version of KaTeX that's embedded in the file.
>>
>
> The guide you referenced is for an old way to do Native. That API is
> obsolete.
>
>
> --
> There is NO FATE, we are the creators.
> blog: http://damoc.ro/
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/elm-discuss/eusppnDgN-A/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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] Local third-party packages

[Lyle Kopnicky]

What's the best way of referencing third-party packages in another 
directory on the same machine? I'm talking about a package that isn't 
available in the community package directory, but is available on GitHub. I 
realize YMMV with such packages. Specifically, in this case, 
https://github.com/bsouthga/elm-katex.

I tried creating a symlink in my project to it, and adding its source 
directory to my elm-package.json, along with the native-modules: true flag.

The problem is that var _bsouthga$elm_katex$Native_KaTeX is hard-coded in 
the native JS file. But when I build my project, because I'm using the 
default project URL, it gets referenced as _user$project$Native_KaTeX, 
which doesn't match. It seems the author was 
copying 
https://github.com/evancz/elm-markdown/blob/master/src/Native/Markdown.js, 
which uses the same convention. However, since that file is a community 
package, when it's installed by the package manager, it will actually get 
referenced correctly.

So I wonder if I can use elm-package to install a package from another 
directory, so hopefully the references will work out right?

Another possibility is given by looking 
at 
https://github.com/eeue56/take-home/wiki/Writing-your-first-Elm-Native-module. 
Here the author shows some very different boilerplate, which doesn't seem 
to involve the project name in the variable names. I'd have to copy the 
elm-katex code into my own project and tweak it a bit, but that's OK for 
now as I'll only be building/running my project locally for the foreseeable 
future. Also I'd be able to update the version of KaTeX that's embedded in 
the file.

Any other thoughts?

Thanks,
Lyle

-- 
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.