@eyorble @JackLaVigne I have come to the conclusion that my question mathematica.stackexchange.com/questions/162935/… is poorly posed. I will delete it in a day or two. I want to thank you two for the effort you put into attempting to answer it. I am very sorry that I caused you to waste valuable time on a bad question. If I can find a way to formulate it clearly, I will post a new question on this issue,

tmp = Import["large/50MB/file", "CSV"]

ByteCount[tmp]

285513160

Then I make an association:

assoc = AssociationThread[First[tmp], #] & /@ Rest[tmp];

ByteCount[assoc]

2031669656

It is reasonable to be expecting that the byte count of the association would be that large?

the assoc has been made correctly in so far as queries of the data set I make from it are as expected for known data.

Other info: Length[tmp]=517228; Length[First[tmp]]=21. i.e. table with close to 11 million entries.

@Szabolcs No I have not reported my issues with Subgraph yet

@VitaliyKaurov I was sure I linked to the PR, but indeed I did not. I have fixed this now.

@b3m2a1 About your GitBook: When I see this right, GitBook also uses Jekyll in the background which means we should get syntax highlighting with the Rogue highlighter I worked on.

Locally, this should be possible right now, but only when my PR is merged it will be available out of the box for GitBooks that are completely built online.

ClearAll[foo];
Options[foo] = {"Style" -> Red};
foo[OptionsPattern[]] :=
 DynamicModule[{}, Framed[OptionValue["Style"]],
  BaseStyle -> {FrameBoxOptions -> {FrameStyle ->
       OptionValue["Style"]}}]
foo[]
InputForm@foo[]

Is it expected that OptionValue is left unevaluated in DynamicModule options?

Create (Header + Main area + Settings pane) notebook layout?

@b3m2a1 @MikeHoneychurch @halirutan ^

@Kuba Good luck with this one. A pain, I can tell you since the grid layout that is used in Mathematica cannot create something like this is a flexible manner.

I just looked at the picture though, but I had similar difficulties in the past.

@halirutan My main point is to put pressure :) This is not a new problem I have, this was always a problem for me. I'm just tired of partial solutions and filling it with patches for longstanding bugs.

@halirutan thank you

@Kuba +1. Are there any tech. reasons why the cloud FE could not ("some day") completely replace the desktop FE (it would be possible to run this cloud FE locally on desktops) ? As you said, they maintain/develop 3 (maybe more) FEs ...and for example will the layout you design on desktop work with cloud and iOS and probably Android. From the user and developer point of view it should be better to have a unique framework to avoid wasting time (which actually is one the main idea with MMA).

@b3m2a1 - more twitch fun now

@JasonB. Nice. I always enjoy watching this chem. dev. stuff.

@JasonB. as an end user I think avoiding "System`"-level function bloat would be preferable. Like Chemistry`MoleculePart or whatever the final name was seems like a useful idea, but System`MoleculePart would, I think, add unnecessary stuff to the top-level context.

@b3m2a1 - I agree. originally I was trying to write this like user21's FEM stuff, where you need to load the context to get the symbols

I'll still argue against having FormalCharges or MassNumbers being symbols.

After that meeting, I still don't understand how MoleculePart is supposed to work - and how it would return a property value. Seems to me that PropertyValue is the right function

@JasonB. I think the Property stuff needs an overhaul before it really gets used. @Szabolcs can comment more on that. I'd imagine something like MoleculePart to be just an accessor function like Lookup or whatever. It'd act as the true implementation of property access for a Molecule object. Then PropertyValue would be layered on via UpValues to provide a system-level use for it.

I guess essentially I'm picturing something like Association where you have Lookup which is the true, vectorized form of Association querying, but then you have the [] syntax as well.

This analogy isn't perfect, of course, as there's a custom implementation of Take for Association which isn't really exposed anywhere as best I know.

@JasonB. I'm biased though, because this is actually how implemented property-access for my own chemistry paclet. i.e. I made a function ChemGet which acts like a Lookup and but provided [] access too.

e.g.:

<< ChemTools`Objects`

wat = ChemImport["Water"];

ChemGet[wat, "Atoms"] // ChemGet["ObjectType"]

{"Atom", "Atom", "Atom"}

wat["Atoms"] // ChemGet["ObjectType"]

{"Atom", "Atom", "Atom"}

Instead of [] access then I'd imagine PropertyValue access.

@Kuba Well, DynamicModule is HoldAll, so naturally the question when things in it are evaluated comes up. It gets instantiated by the FE. So I think you have a good understanding of how the variables are instantiated and the body executed. It seems undocumented what is done with the options. Clearly (yes?), the options are meant for the FE to handle. Apparently, the FE does not call the kernel to evaluate them, unless it encounters Dynamic[expr] as an option value.

ClearAll[foo];
Options[foo] = {"Style" -> Red};
foo[OptionsPattern[]] :=
 DynamicModule[{glurg = Blue}, Framed[OptionValue["Style"]],
  BaseStyle -> {FrameBoxOptions -> {FrameStyle -> glurg}}]
foo[]
InputForm@foo[]

ClearAll[foo];
Options[foo] = {"Style" -> Red};
glurg = Blue;
foo[OptionsPattern[]] :=
 DynamicModule[{}, Framed[OptionValue["Style"]],
  BaseStyle -> {FrameBoxOptions -> {FrameStyle -> glurg}}]
foo[]
InputForm@foo[]

ClearAll[foo];
Options[foo] = {"Style" -> Red};
glurg = Blue;
foo[OptionsPattern[]] :=
 DynamicModule[{}, Framed[OptionValue["Style"]],
  BaseStyle -> {FrameBoxOptions -> {FrameStyle ->
       Dynamic@OptionValue["Style"]}}]
foo[]
InputForm@foo[]

The localized variables and Dynamic expressions are handled fine. The global variable glurg (middle example) is unevaluated and gives a pink-box error.

@MichaelE2 There is an evaluation step before FE takes charge and I thought it can happen then. Don't know what to expect but I think it probably is to be expected.