Add default selector to all components

Before having the ability to just add data-test attributes to any component (available since 0.1.0), I was using a Mixin like the following which I manually added to each and every component:
Ember.Mixin.create({
  attributeBindings: 'data-test-selector',

  'data-test-selector': computed(function() {
    return Object.getPrototypeOf(this)._debugContainerKey.replace(/^component:/, '');
  })
});

The new version of this addon is truly great in that I can assign data-test attributes everywhere and they just work, and everything is cleanly wiped out for production builds. But the missing piece is still having a default attribute, so I have not to assign them for each and every component.
I removed the afore mentioned mixin and replaced it with an vendor-import approach that you also used, which works and would be fine for me.
But I wonder if it would make sense to add that by default, so this comes for free for every user!?
For example this comes handy when testing components with ember-cli-page-object, so every page-object-components .scope (http://ember-cli-page-object.js.org/docs/v1.8.x/components#scopes) can just be set to the default test-selector for that component.
Should be easy to implement, I can pull a PR together if you guys agree on this!

I initially though this was a good idea as well but @bcardarella and @lukemelia convinced me it's not so we have decided we won't add that - see #26 for a lengthy discussion about the topic.

@marcoow Thanks for pointing this out, did not know this has been discussed before.
While understanding the argument, I think there are other valid ones as well. Most importantly a pragmatic one, as I don't want to manually assign selectors in an app with something like a hundred components. And if I would have to, I would certainly just use the same names as the component, what reason would I have to assign a different name? So no difference...
For the renaming use case, would not be a big deal, if using ember-cli-page-object it's one line in one file. If not you could still just override the default selector to make it the same as it was before.
So far have not renamed a single component in this current app, but definitely would have to assign >100 component selectors...
So I would come to a different conclusion. But that's ok, no big deal. Just hope that other (newbie) users are ok with this as well...

While understanding the argument, I think there are other valid ones as well. Most importantly a pragmatic one, as I don't want to manually assign selectors in an app with something like a hundred components. And if I would have to, I would certainly just use the same names as the component, what reason would I have to assign a different name? So no difference...

The reasoning behind this decision is that it would encourage brittle tests. Actually when looking at the DOM from the perspective of an acceptance or integration test you shouldn't care what component renders a particular element but instead you care about what a particular element "means" in the context of the text. Also the same component might mean different things in different contexts (think of e.g. a {{confirm-button}} component that could be used for deleting or blocking a user etc.). Tests should not be coupled to the use of concrete components as they should also not break when e.g. the component is renamed or replaced with a different but the tested functionality is still intact.
Of course you can always define your own mixin that assigns a data attribute that equals the component's name.

@marcoow @simonihmig as I mentioned a few days ago I'm on the fence here. I tend to agree that during refactoring this might cause more work, but then again you have a lot more work up front now to actually setup the selectors.
I personally would be okay with implementing this, as long as it's possible to disable it in the plugin config, but I think @marcoow has pretty strong feelings about this 😉

Yeah, I initially had pretty strong feelings supporting this but was convinced I should have pretty strong feelings against it actually ;)
Renaming the component isn't really the only problem. You might also refactors whole component structures or move from one addon to another so that the component name changes because of that or even replace the component with a native element (think of the above example where the {{confirm-button}} might be replaced with a regular button). In all these scenarios the functionality under test might stay intact perfectly well and the test shouldn't break.

I tend to agree that during refactoring this might cause more work, but then again you have a lot more work up front now to actually setup the selectors.

😉
I'm not quite convinced yet that the work during refactoring is that much larger than the work for the initial setup.
Since many people are asking for this there is certainly a demand for such a feature and that is mainly the reason why I think it would make sense to offer this as an option. We could still warn about the implications on using it in the README.

I'd say it's easy enough to just add an initializer or so that does it per app actually. I think it's important to not support something that would be considered a bad practice (for the reasons given above) in an addon like this.

I don't want to have the same conversation as #26 again, but I'll just add:

there is not really any such thing as "initial setup". In practice, you add data-test selectors as you write tests
The entire purpose of using this addon is to keep your acceptance tests stable in the face of refactorings that don't actually affect functionality. The proposed feature would create Connascence of Name, that is changing the name of components (which don't affect the end user) would cause you to have to update acceptance tests despite the fact that nothing has changed for the user.

there is not really any such thing as "initial setup". In practice, you add data-test selectors as you write tests

Well, maybe we have used this in a different (wrong?) way, but actually we did provide each component a test selector upfront (through the use of the mentioned mixin). For low level things like a button we certainly overrode this is certain places to distinguish them by their function (save, cancel, whatever). But for more high level components we were actually sticking to the default selector and had no need to customize it.
Also as I mentioned, we used this in conjunction with ember-cli-page-object, that gives you an extra (somewhat different) level of abstraction and decoupling from your tests, so having to change selectors during refactorings was no real concern to us. (as this would happen in just one place)
Anyways, as I said I can live with it. Would still support an option as @Turbo87 suggested, but that decision is now yours! :)


HunterPlugin: Fix deadfall trap

The player is for some traps 2 squares away when setting up the trap

I couldn't find any traps where that would be an issue when i checked, but i'll take your word for it :) Now split manical monkey and deadfall traps


Ubuntu / iGPU: Ah snap

Ah snap! There was no error compiling the test kernel or running it, but the numbers don't check out. Please report your browser (+ version) and hardware configuration to us, so we can try to fix this. Deviation was 0.3373333334457129.
console:
Values are: 0.00900000031106174 and 1.0210000006482005
Chrome on Ubuntu 14.04 64 bit on Intel NUC i3-4010U

Deviation was 0.020666667027398944.
Values are:
0.0020000000949949026
and
0.06400000117719173
on Firefox Developer Edition 51.0a2 (2016-10-17) (64-bit)

Moved to #1


Add telemetry completeness tests

Motivation

Adds a new test for telemetry completeness, ensuring what is specified in dd-go is present in our individual libraries
With the current implementation, this tests for telemetry of an empty configuration which may be lossy in some languages
These tests somewhat eliminate the need for equivalent tests in dd-trace-js and tests in dd-trace-dotnet (missing ref)
Note for reviewer: I'm a bit suspicious about the correctness of this line, but it seems to better match what is on this notebook
Changes

Adds a test across languages
Workflow

⚠ Create your PR as draft ⚠
Work on you PR until the CI passes (if something not related to your task is failing, you can ignore it)
Mark it as ready for review

Test logic is modified? -> Get a review from RFC owner. We're working on refining the codeowners file quickly.
Framework is modified, or non obvious usage of it -> get a review from R&P team

:rocket: Once your PR is reviewed, you can merge it!
🛟 #apm-shared-testing 🛟
Reviewer checklist

[x] If PR title starts with [<language>], double-check that only <language> is impacted by the change
[ ] No system-tests internal is modified. Otherwise, I have the approval from R&P team
[ ] CI is green, or failing jobs are not related to this change (and you are 100% sure about this statement)
[ ] A docker base image is modified?

[ ] the relevant build-XXX-image label is present

[ ] A scenario is added (or removed)?

[ ] Get a review from R&P team

CI is failing on the new test

@cbeauchesne I've fixed the CI and all failures are now unrelated to the new test. Please re-review 🙏

Could you also update your branch, it'll fix php errors


Fix unknown doc attribute Hidden at nightly

The Hidden doc attribute it's no longer valid at nightly

Also breaks my build.

To be clear this is a rustc regression (https://github.com/rust-lang/rust/pull/82662), and we hope to fix it in the next nightly (https://github.com/rust-lang/rust/pull/82702), but until then it would be really great if this could be landed with a version bump

Thanks for the pull request!


Self id form

Implementation description

Implemented self-id section of the application form.

Steps to test

Go to /apply
Play with the select inputs

What should reviewers focus on?

Should I put the constants in a separate folder or should I just keep them here?
I remember @lambo-liu saying I don't need to worry about state right now, I implemented it just as a POC of how I would implement to reference in case I'd need to integrate it into the higher state.
Is the styling ok?

Checklist

[x] My PR name is descriptive and in imperative tense
[x] I have run the linter
[x] I have requested a review from other devs who have background knowledge on this PR or who will be building on top of this PR

Please change the PR name to imperative tense


UDS client responding with a functional flow control frame to a physically addressed request

Hi @driftregion ,
when sending a physically addressed RDBI request to an ECU, that answers with a multi-frame RDBI response, the client sends two flow control frames, one that is physically addressed and the other functionally. Here is a log with candump:
(1688347721.008952) can0 18DAF140#103562FD13584355  /* response to RDBI request */
(1688347721.009126) can0 18DB00F1#301003  /* functionally addressed response even if the request was physically addressed */
(1688347721.009231) can0 18DA40F1#301003 /* physically addressed response */
(1688347721.012025) can0 18DAF140#215F544848000000

Sending two flow control frames makes the ECU answer twice, which is unnecessary and unwanted.
I'm not able to explain myself why this happens since in the function tp_recv the code for reading from the socket reads from the physical link first:
struct {
        int fd;
        UDSTpAddr_t ta_type;
    } arr[] = {{impl->phys_fd, kTpAddrTypePhysical}, {impl->func_fd, kTpAddrTypeFunctional}};
    for (size_t i = 0; i < sizeof(arr) / sizeof(arr[0]); i++) {
        ret = read(arr[i].fd, buf, count);
        ...
        ...

After reading from the physical link, the socket should get the answer it needs and then not read another time from the functional link. Do you have an idea why this could be happening? If you need more info to the context or execute code, just let me know and thanks in advance!

Hi @muehlke , I agree this is undesirable behavior.
which transport layer implementation are you using?
if isotp-c, can you share the section of code where you call isotp_on_can_message?

Hi @driftregion , I'm using the Linux ISOTP kernel module.

We may be using the kernel module incorrectly. There's a flag CAN_ISOTP_LISTEN_MODE that probably needs setting on the socket that's used to send functional requests by the client:
https://elixir.bootlin.com/linux/v6.5.8/source/include/uapi/linux/can/isotp.h#L138
Could you try setting this flag and see if this solves the problem?

Hi,
I tried setting the flag as you mentioned like the following before setting the can_isotp_fc_options:
struct can_isotp_options opts;
memset(&opts, 0, sizeof(opts));
opts.flags |= CAN_ISOTP_LISTEN_MODE;
if (setsockopt(fd, SOL_CAN_ISOTP, CAN_ISOTP_OPTS, &opts, sizeof(opts)) < 0) {
    perror("setsockopt (isotp_options):");
    return -1;
}

and it solved the problem 👍  The only issue would be the method definition. It is necessary to distinguish between opening a socket for the physical and functional ID of the UDS client. Obviously if both sockets are opened with this set flag, then the client doesn't send a FC frame from its physical ID causing a timeout.
One idea would be to change the definition to something like:
static int LinuxSockBind(const char *if_name, uint32_t rxid, uint32_t txid, bool funcSocket)
where ``funcSocket` is used to indicate whether the socket to be bound is a functional one:
if (funcSocket) {
    struct can_isotp_options opts;
    memset(&opts, 0, sizeof(opts));
    opts.flags |= CAN_ISOTP_LISTEN_MODE;
    if (setsockopt(fd, SOL_CAN_ISOTP, CAN_ISOTP_OPTS, &opts, sizeof(opts)) < 0) {
        perror("setsockopt (isotp_options):");
        return -1;
    }
}

to then change LinuxSockTpOpen to:
...
hdl->poll = tp_poll;
impl->phys_fd = LinuxSockBind(if_name, phys_rxid, phys_txid, false);
impl->func_fd = LinuxSockBind(if_name, func_rxid, func_txid, true);
...

This has been fixed in #21

I see, you moved the implementation to src/tp/isotp_sock.c
Thanks for addressing this issue!


Clean up gen-ca example YAMLs

I think the amount of comments in the current versions makes it hard to read/makes it seem more complicated than it is:
 providerName: "gcp"
 providerConfig:
   gcp:
     #This will hold the full CA name for the certificate authority you created on GCP
     casCAName: "projects/{project-id}/locations/{location}/certificateAuthorities/{YourCA}"

 certificateParameters:
   secretOptions:
     # Namespace where 'cacerts' Kubernetes secret is created on your target cluster
     istioCANamespace: "istio-system"
     # SecretFilePath is the file path used to store the Kubernetes Secret in yaml format
     secretFilePath:
     # Force flag when enabled forcefully deletes the `cacerts` secret
     # in istioNamespace, and creates a new one.
     force: true
   caOptions:
     # ValidityDays represents the number of validity days before the CA expires.
     validityDays: 365
     # KeyLength is the length(bits) of Key to be created
     keyLength: 2048
     # This is x509.CertificateRequest. Only a few fields are shown below
     certSigningRequestParams:
       subject:
         commonname: "getistio.example.io"
         country:
           - "US"
         locality:
           - "Sunnyvale"
         organization:
           - "Istio"
         organizationunit:
           - "engineering"
       emailaddresses:
         -<EMAIL_ADDRESS>
I'd rather we simplify it a bit like:
 providerName: "gcp"
 providerConfig:
   gcp:
     #This will hold the full CA name for the certificate authority you created on GCP
     casCAName: "projects/{project-id}/locations/{location}/certificateAuthorities/{YourCA}"

 certificateParameters:
   secretOptions:
     istioCANamespace: "istio-system" # namespace where `cacerts` secrets lives
     force: true # force delete the `cacerts` secret and replace it with this new one
   caOptions:
     validityDays: 365 # validity days before the CA expires
     keyLength: 2048  # length(bits) of Key to be created
     certSigningRequestParams: # x509.CertificateRequest; most fields omitted
       subject:
         commonname: "getistio.example.io"
         country:
           - "US"
         locality:
           - "Sunnyvale"
         organization:
           - "Istio"
         organizationunit:
           - "engineering"
       emailaddresses:
         -<EMAIL_ADDRESS>

Leaving this open until https://github.com/tetratelabs/getistio/pull/5 is merged/new release is created as that will require us to change the docs again.

Actually, looks like #136 covers the renaming, so I am closing this.


libfmt support

libfmt is really nice, fast and safe library for string formatting, and it would be amazing to have it as string formatter instead of printf.
I know that g3log wants to be without any external dependencies, but this can be as optional dependency / feature.
Cheers

Yup I know of it. It would be a breaking change however for the LOGF users.
If a g4log would be created then it’s something I would look into

Cool! Should I keep this issue opened?

No need. I don’t have that planned anytime soon and it would be a different repo


Investigate TypeConverter support for dynamic

W.R.T. #109 ; TypeConverter would provide a nicer way to determine the legal cast types w/o doing trial casts.
That's assuming it can be made to work with dynamic, which at least passes the plausibility smell test.

One wrinkle is that the CanConvert calls on TypeConverter do not always provide the actual object to converted.  It assumes that if any instance can be converted, then all instances can be converted.
This is obviously not true for JSON, and especially not true for Jil's JsonObject.  However, using ICustomTypeDescriptor gives us the opportunity to bind a TypeConverter implementation to a particular JsonObject instance.  Given that we can make the CanConvert calls work.

Fixed now that https://github.com/kevin-montrose/Jil/tree/type-converter is merged in.


Error while saving pdf

https://medium.com/machine-learning-for-humans/why-machine-learning-matters-6164faf1df12
https://medium.com/@v_maini/supervised-learning-740383a2feab
https://medium.com/@v_maini/supervised-learning-2-5c1c23f3560d
https://medium.com/@v_maini/supervised-learning-3-b1551b9c4930
/ Saving PDF(node:1512) UnhandledPromiseRejectionWarning: TimeoutError: Navigation Timeout Exceeded: 30000ms exceeded
    at Promise.then (C:\Users\...\github\percollate\node_modules\puppeteer\lib\FrameManager.js:1230:21)
    at <anonymous>
  -- ASYNC --
    at Frame.<anonymous> (C:\Users\...\github\percollate\node_modules\puppeteer\lib\helper.js:144:27)
    at Page.goto (C:\Users\uc245524\github\percollate\node_modules\puppeteer\lib\Page.js:579:49)
    at Page.<anonymous> (C:\Users\...\github\percollate\node_modules\puppeteer\lib\helper.js:145:23)
    at bundle (C:\Users\...\github\percollate\index.js:201:13)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:188:7)

Increased the timeout. Worked fine now.
https://github.com/butu5/percollate/commit/13db308181d3e17bd2a25145103bb09f0ac8442f

I am thinking pulling images takes time. Just thinking.. will debug more.

I've increased the timeout to 2 minutes, although it seems unlikely that it needs so much time for fetching. It may be that it hangs on a request we're not seeing. In any case, I've added logging for the individual resources.


Current Prisma2 limitations.

I can't wait to try out Prisma2 in a new project, but there's a few things I'd like to know if it's supported or not. Is there link where I can see if certain features have been implemented?. Things like JSON field, check constraint, aggregates, etc. Much appreciated!

Hi,
We list some of the limitations here: https://github.com/prisma/prisma2/blob/master/docs/limitations.md
You can look into the issue for other limitations.
Unfortunately, the things that you have mentioned are also work in progress 😅.
You can check the specs repository on what is coming: https://github.com/prisma/specs

Cool, tyvm! I don't see JSON fields or check constraint in  the specs, I hope they'll be added.

JSON fields are part of the native type. We will not only support JSON type but all other database types in the future: https://github.com/prisma/specs/tree/master/schema#type-definitions-provided-by-connectors. JSON will just another postgres type.
I opened a new spec issue for check constraints though: https://github.com/prisma/specs/issues/344

Hey, I'm working with protobuf, and I get a Long type for uint64 and there is no way actually to save more than an Int in prisma?

Longs are also part of type declarations as described by @matthewmueller here: https://github.com/prisma/photonjs/issues/170#issuecomment-517369338
That is a long ongoing work that will remove many limitations. It still requires much product and implementation work so it is taking time.

Question answered!


Revert linker warning series

Revert this series of changes which has been causing various issues. Will reintroduce once we have covered all corner cases.

Codecov Report

Merging #10559 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master   #10559   +/-   ##
=======================================
  Coverage   53.34%   53.34%
=======================================
  Files         210      210
  Lines       25825    25825
  Branches     5686     5686
=======================================
  Hits        13776    13776
  Misses       9734     9734
  Partials     2315     2315

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2c7636b...01c9489. Read the comment docs.

due to the large number of failures merging ASAP while we wait for a proper and tested fix.


How to add TagListView in textField?

Sorry, Im beginner. If I want to add tag in my textField.How to do this?
I have tried on my own.But I also fail to do it.
This is my code:
https://github.com/Bruce9487/TagViewTest

So why you want to display the TagListView in a textfield?

If you want to show tokens like in Mail.app, we don’t support that yet.


trajectory.to_mdtraj() not parsing box_vectors

While writing my own CV I noticed a difference between OPS wrapped code and pure mdtraj code. Namely the trajectory.to_mdtraj() doesn't includes the box vectors.
def mindist(snapshot, atom_list1, atom_list2):
    import mdtraj as md
    import itertools
    import numpy as np

    atom_pairs = list(itertools.product(atom_list1, atom_list2))
    #box_vectors = snapshot.box_vectors/snapshot.box_vectors.unit
    #unitcell_vectors = np.asarray([box_vectors])
    trajectory = paths.Trajectory([snapshot]).to_mdtraj()
    #trajectory.unitcell_vectors = unitcell_vectors
    all_distances = md.compute_distances(trajectory, atom_pairs=atom_pairs)
    mindist = min(all_distances[0])
    return mindist

my_cv = paths.FunctionCV("d_min_gly60_gly12", mindist, atom_list1=gln61, atom_list2=gly12)

When I uncomment the box_vector code above:

Excellent catch. That should not be the case. I will make a quick PR to fix this. Thanks

Already have it on the way, @jhprinz


Update Blog “cat”

Automatically generated by Netlify CMS

👷 Deploy Preview for kidskingdom processing.

Name
Link

🔨 Latest commit
c944d73362a2a8d8a877f79aa61ab9758b7fe8b2

🔍 Latest deploy log
https://app.netlify.com/sites/kidskingdom/deploys/63b7e78034a852000811090c


[improve][broker] Remove uneffective solution for reducing GC pressure

Motivation
The PublisherStatsImpl and ConsumerStatsImpl classes contain an uneffective solution for reducing GC pressure.
This code is confusing and doesn't help. Instead, ordinary fields are used.
The solution was originally introduced by #1480.
Modifications

remove the uneffective solution
add a solution for reducing unnecessary object creation by sharing the client source address and port String object across all consumer and publisher stats on a single connection.

Documentation

[ ] doc
[ ] doc-required
[x] doc-not-needed
[ ] doc-complete

/pulsarbot rerun-failure-checks


Integrates django-modeltranslation as an optional app à la south

I finally decided to take the time to integrate my wrapper shown in #106 into mezzanine. The code is far better that way.
One downside though:
======================================================================
ERROR: test_mulisite (mezzanine.core.tests.CoreTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/mathias/PkgBuilding/mezzanine_devel/lib/python3.4/site-packages/django/db/models/fields/related.py", line 303, in __get__
    rel_obj = getattr(instance, self.cache_name)
AttributeError: 'RichTextPage' object has no attribute '_page_ptr_cache'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/mathias/PkgBuilding/mezzanine_devel/mezzanine/mezzanine/core/tests.py", line 238, in test_mulisite
    site1.delete()
  File "/home/mathias/PkgBuilding/mezzanine_devel/lib/python3.4/site-packages/django/db/models/base.py", line 694, in delete
    collector.collect([self])
  File "/home/mathias/PkgBuilding/mezzanine_devel/lib/python3.4/site-packages/django/db/models/deletion.py", line 197, in collect
    field.rel.on_delete(self, field, sub_objs, self.using)
  File "/home/mathias/PkgBuilding/mezzanine_devel/lib/python3.4/site-packages/django/db/models/deletion.py", line 17, in CASCADE
    source_attr=field.name, nullable=field.null)
  File "/home/mathias/PkgBuilding/mezzanine_devel/lib/python3.4/site-packages/django/db/models/deletion.py", line 197, in collect
    field.rel.on_delete(self, field, sub_objs, self.using)
  File "/home/mathias/PkgBuilding/mezzanine_devel/lib/python3.4/site-packages/django/db/models/deletion.py", line 17, in CASCADE
    source_attr=field.name, nullable=field.null)
  File "/home/mathias/PkgBuilding/mezzanine_devel/lib/python3.4/site-packages/django/db/models/deletion.py", line 181, in collect
    parent_objs = [getattr(obj, ptr.name) for obj in new_objs]
  File "/home/mathias/PkgBuilding/mezzanine_devel/lib/python3.4/site-packages/django/db/models/deletion.py", line 181, in <listcomp>
    parent_objs = [getattr(obj, ptr.name) for obj in new_objs]
  File "/home/mathias/PkgBuilding/mezzanine_devel/lib/python3.4/site-packages/django/db/models/fields/related.py", line 320, in __get__
    rel_obj = qs.get()
  File "/home/mathias/PkgBuilding/mezzanine_devel/lib/python3.4/site-packages/django/db/models/query.py", line 307, in get
    self.model._meta.object_name)
mezzanine.pages.models.DoesNotExist: Page matching query does not exist.

I tried to investigate why this is happening but I lack knowledge about the internals of mezzanine and django-modeltranslation. It can be that when models are registered for translation, their managers are not correctly patched but I’m very unsure about this.
Anyway, this issue has a workaround since it happens only when one tries to delete a Site with remaining Pages attached to it. If all pages are deleted beforehand, the Site delete smoothly.

Any on this front? Is it supposed to be any merge soon?

Looking very good! The only issue I see right now (at least on the Admin side) is that inlines are not tabbed (for example, in Galleries and Forms). I'm not sure if Model Translation provides classes for them.

Hi Mathias, thank you for taking care of this long awaited feature request! Looking forward for this work to me merged into the official mezzanine repository.

So, off the top of my head, this is the list of things that need to be done:

[ ] Add some language switching mechanism to Inlines in the Admin.
[ ] Add some language switching mechanism to localizable settings in the Settings Admin.
[ ] Catch up with master to account for all changes in Mezzanine so far.
[ ] Write tests for translation related stuff.

@stephenmcd, what do you think about these points? Anything else that needs to be done before merge? :)

Just for reference, Model Translation DOES include Admin classes for inline Admins. https://django-modeltranslation.readthedocs.org/en/latest/admin.html#admin-inlines

It does but these are not tabbed. Tabbed ones are only regular ones : https://django-modeltranslation.readthedocs.org/en/latest/admin.html#tabbed-translation-fields-admin-classes
Maybe a feature request to the modeltranslation team will avoid us to duplicate what they could come up with some day.

Hmm, according to this issue in model-translation tabbed inlines are supported (both the stacked and tabular flavors). Perhaps Mezzanine's custom inlines are messing something up?

I am happy with non tabbed inlines, as long as I§m able to create multilingual sites.. If we use django-modeltranslation the models can be generated with non tabbed inlines. If later on django-modeltranslation gets support for tabbed inlines we can migrate easier because we don't need to touch the db schema. We may need to replace the admin classes but it is far less painful, than migrating a db schema.
@Kniyl but I agree that anything related to customizing modeltranslation should be done in that project.

@jerivas that checklist looks correct. As always, thanks your help here.

Regarding slugs: My take on this is that we only need slugs generated in the default language and use i18n_patterns in the url to differentiate between languages. Just the way it is done on the admin site, and in django. If we postpone the decision and go with a temporary one, which may change in the future, we also need to take care of backward compatibility, i.e.: providing redirects for old urls to new ones, to overcome potential broken external backlinks. Just keeping SEO in mind.
What are the pros and cons of implementing one solution over the other?
@jerivas @stephenmcd there might be another item to your list, and that is enhancing sitemap generation. https://support.google.com/webmasters/answer/189077?hl=en. (Again thinking of SEO)

@jerivas You’re right. I just made a new django site with modeltranslation and both inlines are tabbed. Thus the issue seems to be with mezzanine or perhaps grappelli. I’ll try to figure out what are the requirements for modeltranslation that exist in plain django but not in mezzanine.

@Lumpusz both translated slugs and slugs generated in the default language registered with i18n_patterns are valid approaches. The latter, however is clearly the easiest one since there is nothing more to do. If someone wants to include slugs inside i18n_patterns, it is also their responsibility to add hreflang support in their templates/base.html
If the choice is to provide translated slugs, then I agree that hreflang support should be considered. There are, however, two main drawbacks to this approach : settings.BLOG_SLUG (which might be solved by using a tupple or a dictionnary instead of a single string) and slug = / required to have the homepage within the page tree.
I have the same feeling, slugs in the default language + i18n_patterns if needed (which is already the case) seems safer.

@Kniyl Sorry I meant hreflang support in sitemaps, here is the correct link https://support.google.com/webmasters/answer/2620865?hl=en.
@stephenmcd, @jerivas  do you have anything against going with the slugs to be generated in the default language, and using i18n_patterns?

I had a feeling that tabbed inlines disapeared because of grappelli and it seems to be it.
The way modeltranslation/static/modeltranslation/js/tabbed_translation_fields.js tracks translation fields and adds the tabs to them is heavily dependent on the plain django templates. When translation fields are found (and especially for inlines) they track their container with $(el).closest('.form-row') which django uses as a class for each row in tabular inlines. They also track the table element to get rid of duplicates titles.
Unfortunately, grappelli_safe got rid of both. You can convince yourself by editing grappelli_safe/templates/admin/edit_inline/tabular.html and add form-row to the class attribute of the div at line 38. TabularInlines will now display translation tabs but they will get messy and disapear. And titles will still display for each languages.
So we have two options to get tabbed inlines. Either we change grappelli_safe to use a table instead of a div at line 11 and the form-row class at line 38 and whatever else is needed to get modeltranslation’s javascript to work, or we duplicate tabbed_translation_fields.js into mezzanine and we modify it for the hierarchy we are working with.
Imo, the second one seems more interesting and less painfull. I’ll try to come up with something in the near future. And may be I’ll get two birds with one stone and tackle the tabbed settings issue too.

@Lumpusz I would prefer translatable slugs for consistency. However, this is merely a personal opinion and in the end is Steve's decision to make.
@Kniyl That's good news. Let us know when you've got something and I will give it a test run.

If translatable slugs is what someone wants, then really wants the point of all this? Why not just construct a page tree with the primary nodes representing each language, the secondary nodes representing the primary pages per language, and so forth.
I honestly take this thinking further and question the need for translatable models at all - in my mind it actually adds a huge constraint to how a multi-lingual site works, in that every page needs to be translated in every language. Expanding on that - If the pages for each language don't have a relationship with each other, then you're no longer restricted by the above - one site may have extra pages that are only applicable to a particular language. Then the actual implementation of differentiation between languages on a site can occur via either a multi-site setup, eg: en.example.com, jp.example.com, etc, or via languages as root node in the page tree, eg example.com/en/, example.com/jp, etc.
Is the end result of integrating modeltranslation nothing but a nicer admin interface that allows you to edit multiple languages for a single page at once? Because given the restrictions described above and more importantly, the maintenance overhead and future complexity that this introduces to the project (which naturally isn't a primary concern for most of the people involved here), I really question how worthwhile it really is.
PS: This is why every time this and other similarly large features come up, I try and push for it to come together as a third-party package - that removes the maintenance overhead and complexity around future development as a concern, as well as the restrictions described above which would dictate "here's how to do multi-lingual" sites, should modeltranslation actually be integrated directly into Mezzanine.

I've used both approaches described by Steve for clients
(language-specific subdomains and top-level nodes in the page tree for
each language). I describe some of the drawbacks below (if you want all
page trees in all languages to be identical):

Following any of the approaches described above puts the burden of
keeping everything in "sync" between languages on the end user. If
you add some content to a field in one language, you must remember
to go to the "equivalent" page in the other languages and do the
same. In fact, all of these actions must be manually repeated for
every language you have: page creations, page removals, changes in
sort order, changes in page menu options, etc. Model translation
will do away with those.
Using the tree approach makes it complicated to leverage Django's
language switching utilities, as you're not really using i18n
"proper" and have to come up with a way to associate certain slugs
with certain language.
Both of these approaches fail to provide easy "language switching"
for visitors. If you land in a specific page of the site and it is
not in your desired language, you choose to switch languages, but
since there's no one-to-one correspondence between pages, you go to
the home page of your desired language. Good luck hunting for the
page you were looking for in the beginning.

Now, I empathize with Steve because I see how big of a maintenance
burden this will be. Making this a third-party package sounds good to
me, but some hooks will need to be setup in Mezzanine's core; like being
able to choose from which model/admin classes to inherit for Mezzanine's
Displayable, for example.

@jerivas I agree that language specific subdomains are not really an option for production sites, as they introduce way too much maintenance time/cost, and they are very prone to human errors. If we used the tree approach, we could use 99% of django's language switching mechanism to get back to the same translated page that the switching was originated from. According to the docs here https://docs.djangoproject.com/en/1.6/topics/i18n/translation/#the-set-language-redirect-view we can set the redirect url in the language switching form to be the translated version of the current url with slicing:
<input name="next" type="hidden" value="{{ request.get_full_path|slice:'3:' }}" />

I'm also in favor of implementing this as an app, provided, that mezzanine implements the necessary hooks to use customized admin classes.

Correct me if I’m wrong but isn’t modeltranslation an external app and this pull request the necessary hooks to have it integrated within mezzanine?
The whole point of this and #106 is to have an easy-to-use and already integrated solution to manage multi-lingual sites for people that want to. Reading all the comments asking for this kind of feature, I have the feeling that mezzanine’s newcomers don’t even think of the page tree as an alternative to i18n_patterns and, sooner or later, will look after this feature elsewhere. But, as far as this PR is concerned, we’re not forcing anyone to share django-modeltranslation’s view on how multi-lingual sites should be managed. It’s an optional feature that needs to be explicitly enabled by (1) installing django-modeltranslation and (2) activating it with settings.USE_MODELTRANSLATION = True.
And, believe me, I actively try to keep the number of added/modified files to the minimum to reduce the maintenance burden. It is just that:
(1) There are some classes that need to be modified in order to greatly simplify future extensions (stephenmcd/cartridge#187 is really simple from this point of view).
(2) There were some requests that I interpreted as a requirement for the merge (language selector in the templates, translatable settings, tabbed admin) and it keeps adding to the number of modifications involved.
(3) I have a tendency to list every possible fix that comes to the top of my head when I identify an issue and it makes things feel like the solution will be a terrible blob. Whereas it is just my way of asking if I’m right considering one way simpler than the others.
That said, solutions exist to unattractively glue mezzanine and modeltranslation together as well the multi-site and page tree you mentionned. So there is a need of a clear statement of wether we close this PR, #106 and we document that multi-lingual support is not built in mezzanine but there are several solutions to accomplish this, or we continue on this path and make the integration as smooth as possible for those who consider they need this feature.

On the one hand mezzanine would become very attractive to people who want to build mutilingual cms sites, if this feature was integrated into mezzanine itself. On the other hand I understand the hesitation on boarding a new feature.
Considering all that stuff have been going on on the mail lists, forums, multilingual support is a long awaited feature (https://github.com/stephenmcd/mezzanine/issues/106 is opened >3 years). Merging this code into the master repo would mean finding the holy grail for many of us. I was just saying that a 3rd party app which mezzanine was tweaked to, would be better  than any of the solutions out there, if, and only if, the merge can't happen.
All that said I think if Admin classes and files are fairly independent from current codebase, the risk of merging the code is minimal, provided that appropriate test case coverage is also present. As @Kniyl said one can opt to use it or not.

On a side note, I just merged stephenmcd/mezzanine:master into Kniyl/mezzanine:master and resolved the conflicts on my local repo. I’m 400 commits ahead and I’m wondering if they will all show up in here if I push the modifications on github.
Was it the way to go?

Yep, push it to to Kniyl:master and it'll show up here.

Nice, I was affraid that all the 400 commits since my fork would show up too.

@jerivas Thanks for the feedback on my points, that all makes sense. I didn't want to sound like I was derailing the whole idea either, which I kind of felt like after my last comment, but I just wanted to play devil's advocate, particularly from a maintenance perspective.

No problem @stephenmcd, I'm glad we can consider all points of view and make a sound, well-established decision.
So, I went to the Travis build details and it looks like they are all passing (with the exception of one, but it looks like a network error), so I crossed off that item from the list. We still have three pending items. Is it safe to assume after those are completed a merge could happen? :)

Don't hold me to it, but sure, let's give it a try.

I just pushed a version with tabs for tabular inline translation fields. It works and all but... it's kind of ugly when there are more than two or three languages (especially on a form page). I need some help to figure out what would be the best way to handle them : keep stacking them like they do but try to improve the layout or expand the cells to contain them all.
And... Did something change in the travis build config? The push fails with pep8 warnings on files that passed in the previous push and were left unchanged.

Awesome @Kniyl - I think we upgraded the pep8/pyflakes versions a while back, so yes there may be new regressions.
Are you able to post a screenshot or something of the tabbed interface?

Sure! Here you go.

@Kniyl This one seems to be a very good solution to organizing lots of tabs in small places: https://github.com/jasonday/plusTabs

You're right that's a bit of a mess.
Would it be better to somehow leverage the language selector for the admin interface? So choosing to use the admin itself in a particular language would then define the language you're also editing content for.

@Lumpusz plusTabs doesn’t seems to work out of the box. I added plusTabs.min.js before tabbed_translation_fields.js in mezzanine.core.admin.BaseTranslationModelAdmin and changed each tabsContainer.tabs() of tabbed_translation_fields.js into
tabsContainer.plusTabs({
    className: "plus-tabs",
    seeMore: true,
    seeMoreText: "",
    showCount: false,
    expandIcon: "▼",
    dropWidth: "66%",
    sizeTweak: 0
});

The result is... somehow less appealing than before.

@stephenmcd Its worth investigating. I wouldn't choose the admin language as the default editing language since modeltranslation provides settings to exclude languages from translation. But it provides a global switch near the title of the admin form. It might be easier to use it.

It is even simpler to just hide the tabs so that only the global switch is managing the language that shows up. And it also works when USE_L10N is set to False and the admin has a fixed language.

It is even simpler to just hide the tabs so that only the global switch is managing the language that shows up. And it also works when USE_L10N is set to False and the admin has a fixed language.

Cool! That's kinda was I was thinking of.

It should be it. Settings marked as translatable are now grouped and managed with a language switch as the other translation fields. It might need some visual improvement such as hinting which fields are duplicated in other languages, though. But as long as the ToDoList is concerned, there should only be the first item left.
And as far as I can tell re-reading the discussion, it seems that letting the user manage localized urls if they want to is an acceptable solution for anyone (with i18n_patterns being the obvious choice that works out of the box).
So... Nothing more needed?

Tried it out and it's working great. Only problem I see is that the language selector appears over the admin action buttons. Perhaps the action buttons need to be offset down or to the left to make room for the floating drop down.

Just tried it and noticed the same thing - but what I was getting at earlier was, do we really need separate language selectors in the admin for both the UI itself and content, and can we somehow have the translation fields leverage the UI admin selector?

Only downside I see to coupling both selectors (as Matthias noticed) is that model translation and the UI languages might not be the same, and some users might not enable L10N, which disables the UI lang selector.

Thing is, I don't really know where to put this selector. I had it in the header next to the L10N one but it was confusing.
But I agree that its position should be improved. And, imo, it should have a fixed one so the users can access it when they are editing translation fields down below.

I moved the selector down there. Is it better?

Honestly I think it's a really confusing user experience to have two different language selectors, and more often than not the list of ui languages would match the list of content languages.

I agree. And the fact that I don't really know where to put the selector to be both visible and clearly identifiable tends to confirm that.
However, there are currently two issues of using only one selector:

users who set USE_L10N to False won't be able to use a selector at all;
their behavior is completely different. The L10N one redirects to django's set_language on a click, discarding changes when the page is shown again; and the modeltranslation's one just hide/show some divs on the same page on a click.

1 can be easily solved by using {% if settings.USE_L10N or settings.USE_MODELTRANSLATION %} in the template instead of just {% if settings.USE_L10N %}; but for 2... I still didn't have the epiphany to manage that.

Ok… tried to get back on using tabs instead of the global switch to reduce confusion. I combined all tabs from TabularInline into a single one, though, so it is not ugly anymore. Does it seems good enought to be pushed or should I still try something else?

TabularInline:

Settings:

@Kniyl this is the best so far. Do you think that instead of tabs, using radios, only for inlines, would look more appealing? http://jqueryui.com/button/#radio

I rely on the activate (or select for jQuery-UI 1.8) event to trigger all hidden tabs at once. Unfortunately, buttons doesn't seems to provide such hooks.

I think the tabbed approach is still really poor from a user perspective.
Visually the tabs are just hanging there and don't seem to flow from the field itself in a natural way, but please don't give that too much thought - the real problem here is that it's most likely that none of us are particularly great UI designers, so we're really just going around in circles here with all these attempts, in futility to some extent.
More importantly, I think it's quite poor from a user interaction perspective. When I land on a form with 27 translatable fields, I now need to click 27 tabs just to be able to edit the content for one alternative language. If you think about how an actual translator will do this, they'll most likely be translating to a single language, one piece of content at a time - ideally there should only be one selection needed.
Both these issues are solved by the idea I proposed earlier, around leveraging the UI language selector. A translator would login to the system, and can actually use the language selector on the login screen to the same effect. Two issues were raised with this:

USE_L10N may not be configured.

This is actually solved trivially. We pre-set a ton of different settings, based on the values of other settings, inside mezzanine.utils.conf.set_dynamic_settings. If USE_MODELTRANSLATION is set, we can set USE_L10N to True.

List of UI languages mightn't match translation languages.

I think more often than not this won't be the case. A project might have two or three translation languages, and presumably there'd be no real reason to not have those available as UI languages as well. And if there was an edge-case project where more UI languages were required than what can be translated, the translatable language could always fall back to a default in the case of a UI language being selected that translations aren't required for. Not sure how well I've described that, it feels a bit confusing, so I can certainly clarify further there if needed.
As for the actual implementation - surely it's not too much of a stretch to hide the translation selection widgets (tabs, dropdowns, whatever they currently are), and trigger default selection based on grabbing the current UI language?

I’ve been thinking about this lately and I pretty much reached the same conclusion: L10N is not an issue and, since the translation languages should be a subset of the site languages, the differences between the two should not be difficult to handle.
But, the main issue that this approach gives is that the UI language selector triggers a redirect and can potentially lose data that weren't saved beforehand, unlike the selector from modeltranslation which hide/reveals fields on the same page.
I’ll push this solution, though. So we can check how much of a big deal it is compared to its advantages.

That data loss is a hugely important point - we could add some confirmation javascript to the language selector that warns the user and allows them to cancel changing the language, much like gmail does (or did) when you close the browser tab without sending an email that's been written.

Some alternatives off the top of my head, which would require creating a Mezzanine specific implementation of set_language view:

Trigger save() before doing the redirect to avoid data loss. This will hit the DB every time the user changes language and might be slow.
Persist the form data in the request (as POST data) or in the user's sessionStorage. Notice that set_language already uses POST data so we might not want to mess with it.

As a side note: @stephenmcd remember the global model translation switch is available in the current implementation, so a translator won't have to switch each field individually.

I pushed a version that uses the active language to determine which fields to show/hide so you guys can try it and see how it feels. Nothing is done yet to handle the possible data loss.
But (as always, there is a but) a new problem shown up in the name of required fields. Modeltranslation does apply required attributes on the default language for fields that are defined with blank=False. Which means, the default language should be populated before any other otherwise validation errors appears while attempting to save a page. I’ll check later in the documentation of modeltranslation if it is possible to change this behavior but it breaks the natural flow of create, edit, save for whatever language is suitable to the user. However, one may argue that translators shouldn't have to create a page and must only edit those which already are saved with the default language.
Anyway, it adds to the "save" issue and we should consider wether we fix it and keep the nice looking interface or we get back to the terrible looking tabs which work out of the box.
Since modeltranslation won't be a default feature, my personal taste would be to use the tabs (and I think I can manage to get all the tabs synchronize without the need of a global switch, if needed), open an issue saying that the admin looks bad with modeltranslation enabled and hopefully someone with greater design skill will provide a solution.
I think I will cool my brain on that for the next few days, maybe it will help to come up with something that works best.

Thanks for all the effort @Kniyl - really awesome.

The more I try to improve the "one language selector to rule them all" solution, the more I feel that tabs are the way to go. The data loss on language change and the required fields issue are too much of a hassle to handle properly. The approach provides a neat UI, though, and seems intuitive at first. I wish I had found a way to make it smooth for the user, because in its state it can be painful to use.
An other detail that tabs are improving is the ability to easily spot translatable fields. Having a bunch of language names on top of a field will make you know that you can provide translations for them even if you are not aware that the site is supposed to be multi-lingual.
As such, I pushed a version with a new design for tabs, hopping that they will feel better. This way, anyone can fork my repo and try to improve either the tabs version (last commit) or the language selector version (previous commit). This new version keeps in sync all tabs on a page so that when you change a language for a field, all other translatable fields are changed to the same language.
Example by image:

before click:

after click:

I think this approach combines the bests of all alternatives, of all discussed solutions (switching  language on a page with only one click, indicate translatable fields), and eliminates all the worst (confusion with multiple language selectors, as well as combining two similar, but not identical features under one selector.) It also looks better than the previos solution with tabs. Thanks @Kniyl!

@stephenmcd @Kniyl What is still missing for modeltranslation integration to be merged into master?

Free time.

Just reviewed this again and I think the UI works well.
One question - how does caching come into play? Currently with a production deploy, we enable caching of all pages using URLs as keys - it seems like the default setup with modeltranslation at the moment doesn't prefix URLs with language, eg foo.com/en/some-page, so would we end up with cached content for one language showing when another language has been selected?
We'll also need to squash the 30+ commits into one once this is ready, as each commit message gets put into the changelog.

I'll set up a site based on this branch on my VPS to test the caching. In the meantime, how does caching work with logged in users in both the public site and the admin? Because the URLs are the same, but depending on your credentials you'll see different things.

Cool Ed. Caching only comes into play for unauthenticated users, so no problem there.

Okay, it's up and running (http://dev.jerivas.com). As far as I can tell, pages are being correctly rendered for different languages. I've add this string to all templates, so you can see the last time Django parsed the templates: Generated at:  {% now "jS F Y H:i:s" %}.

Thanks Ed. I was surprised it worked, but looking at how the cache keys are generated, they actually take the current language into account, which totally explains it:
https://github.com/stephenmcd/mezzanine/blob/master/mezzanine/utils/cache.py#L91

Huh, that's nice!

So nice to see this becoming part of Mezzanine :)
While getting the live installation ready, I noticed createdb will fail if you have settings.USE_MODELTRANSLATION = True. The workaround is to activate Model Translation only after the initial database installation, which then requires running migrations for the translation fields. Of course, I'm no Model Translation expert, so I wanted to ask @Kniyl what is your recommended approach to:

Start a project with Model Translation serving several languages from the get-go
Add Model Translation to an existing project

Thanks everyone who contributed to this, it's merged now - I've announced it here:
https://groups.google.com/forum/#!topic/mezzanine-users/imE1GEwlvLI

@jerivas To start a Mezzanine project with modeltranslation integration from the start, one has just to set settings.USE_MODELTRANSLATION = True and provide at least two languages in settings.LANGUAGES and it’s done. However, as you said you had an error trying that, I checked again. Everything went fine with Django 1.6, but there is an issue with Django 1.7. Something to do with the manage command update_translation_fields being run too late, I guess. I’ll fix that as soon as possible.
As for adding modeltranslation afterwhile, one has to manually run manage.py update_translation_fields in addition to the two prerequisites mentionned above. And that’s it.
@stephenmcd How do I provide only one big commit ? rebase ?

Hi Stephen,
Thanks for the merge! I'm playing with mezzanine and modeltranslation the whole week now and it plays well. The only thing I can add this far is documentation needs mentioning such a usefull setting as MODELTRANSLATION_FALLBACK_LANGUAGES. Without it you could see blank posts.
Initially I had set
LANGUAGES = (
    ('ru', _('Russian')),
    ('en', _('English')),
)

And the way modeltranslation works Russian became the default (fallback) language. Posts created in Russian were shown when viewing in both Russian and English but posts created in English shown blank lines when viewing site in Russian. After addition of
MODELTRANSLATION_FALLBACK_LANGUAGES = ('ru', 'en')

things settled and no blank lines are shown.

@jerivas @stephenmcd The issue encountered when manage.py createdb is run under Django 1.7 has been fixed in Kniyl/mezzanine@6e03f1719eb01c7767bcb4a3b0ac098ec74fe451, should I make a new pull request for that ?
The issue was that, instead of creating tables from scratch, django 1.7 now creates tables out of migrations. Thus modeltranslation can't hook up and write its own column at creation time. manage.py sync_translation_fields has to be run before manage.py update_translation_fields and everything works fine.

Yes please do - thanks a lot!

when relase mezzanine with multilingual support ???
they are want to write multilingual extention for mezzanine  and  make multilingual page content, if empty  other language content translate from defult language content by google translator?

I can't answer the first question since it depends on @stephenmcd schedule.
For the second one… can you rephrase it? I don't quite understand.

Next release discussed here: https://groups.google.com/d/msg/mezzanine-users/_QWfFVB3RVc/AgcYAjZ7fdkJ


material-ui datepicker usage example?

I'm having hard time to use material-ui's datepicker with redux-form.
When I submit form, values for fields of datepickers are not included in the values parameter.
http://redux-form.com/6.1.1/examples/material-ui/ doesn't show datepicker example.
I tried redux-form-material-ui, and it's giving me errors (https://github.com/erikras/redux-form-material-ui/issues/37 Invalid prop value of type string supplied to DatePicker, expected object.)
https://github.com/erikras/redux-form-material-ui/issues/37
has value={input.value}, what is input.value supposed to represent? current value of the form field entered by user?
The simple example (http://redux-form.com/6.1.1/examples/simple/) has no mention of value  but it works fine without it, and now I need to use value for datePicker and don't see how it fits.

edit

Here's my findings.

input.value: any
The value of this form field. It will be a boolean for checkboxes, and a string for all other input types. If there is no value in the Redux state for this field, it will default to ''. This is to ensure that the input is controlled. If you require that the value be of another type (e.g. Date or Number), you must provide initialValues to your form with the desired type of this field

So I added to MyForm components

const mapStateToProps = (state, ownProps) => {
  let dateRange = {}
  try {
    dateRange = state.batchOperation.selectMethod[DateRangeViewConfig.configName]
  } catch(e) {
  }

  let initialValues = _.defaults({}, dateRange, {
    fromDate: new Date(),
    toDate: new Date(),
  })

  return {
    viewConfigs: state.viewConfigs,
    viewConfig: state.viewConfigs[BatchOperationFormViewConfig.configName],
    batchOperation: state.batchOperation,
    initialValues: initialValues
  }
}

MyForm uses another component which uses DatePicker

  render() {
    return (
      <div>
        <Field
          name="fromDate"
          component={
            ({ input, label, meta: { touched, error }, ...custom }) => {
              console.log("input", input)
              return (
                <DatePicker
                  onChange={this.onChangeFromDate}
                  hintText="from"
                  autoOk={true}
                  value={input.value}
                  />
              )}
        } />
    )
  }

and on date change, I update the redux store
  onChangeFromDate(_, date) {
    this.fromDate = date
    const { dispatch } = this.props
    dispatch(dateRangeSelect(this.fromDate, this.toDate))
  },

Now I can see fromDate/toDate in submit handler. that's good!
But there's another error which I think comes from the store update part.

warning.js:36 Warning: setState(...): Can only update a mounted or mounting component. This usually means you called setState() on an unmounted component. This is a no-op. Please check the code for the DatePickerDialog component

And another problem is {input.value} still points to the old initialValues.
I checked the store value is properly updated with a new date.

Same Problem,
I am using  as DatePicker with a custom input. Redux-Form  does not recognize it when I wrap it inside a Field component, no changes or updates are listened. I can see that it actually makes sense, since I am not actually passing an input component to Redux-Form.
What I am doing is: Field -> DatePicker -> InputComponent.
Any idea how I can make redux-form to bing with my input?
                     <Field component={DatePicker} style='warning' label='DatePicker Warning' />
My datePicker Component that uses a third component called CustomInput
`  const input = this.props.input
const style = this.props.style
const label = this.props.label
return (
  <DatePicker
    customInput={<CustomInput input={input} style={style} label={label} />}
    selected={this.state.startDate}
    onChange={this.handleChange}
  />
)`

This issue doesn't belong to our GitHub issue tracker.
We request you to ask again at StackOverflow, using the redux-form tag, then post the question link here.
As usual, don't forget to explain your question well and show what you've got so far!
This is because the GitHub issue tracker is better suited for discussions related to bugs and improvements of Redux Form.
Meanwhile, StackOverflow is better at keeping popular questions visible, while separating feature-related questions from help-related questions.
Thanks for using Redux Form!


WIP: Group agreements

Implements one part of group agreements - showing an alert when the user has not agreed and letting them agree :)
You can try it out at https://group-agreements--karrot.netlify.com/#/group/1/wall (only group 1 has an agreement set).
You cannot edit the agrerements in the UI yet. In progress...
(note: TERMS OF SERVICE comes from the user specified values in the agreement, it would be whatever the group agreement manager set it to...)

... and with the dialog opened...

Ok, agreement management added!

create initial agreement
minor edit to agreement (users don't need to re-agree)
major change to agreement (users need to re-agree)
remove agreement

Currently nothing is actually restricted on the frontend or the backend, so that is next.
Although this is useful/mergable as it is, so would propose to continue work in future PRs.

Oh, todo:

[ ] hide "Minor edit?" checkbox when creating initial agreement

@stefan-fstaiwan / @Sliverriver /  @brnsolikyl would appreciate your feedback too! Would be nice to know if this will help progress your foodsaving movements :)
You can try it out at https://group-agreements--karrot.netlify.com/ using the same credentials as you might have for any of the dev sites (https://dev.foodsaving.world/ / https://alpha.foodsaving.world/ / https://app.foodsaving.world/), and create a new account if you don't have one, or use<EMAIL_ADDRESS>/ foofoo.
Although, what is not implemented yet is: _ 3.2 If users join a group, joining and accepting should be done in one step_ (from https://github.com/yunity/karrot-frontend/issues/324#issuecomment-312685256).

... although I just realised that as there is no UI for role management yet, you can't manage the agreement anyway :) ... but if you want to try it out, let me know, and I can manually give you the correct role...

I would like to try it out, but I'm confused now, how to do it...

@stefan-fstaiwan I wrote to you in slack, can chat you through it (I need to do a manual step for you...)


Create 0000-01-02-MatthewRose314.md

Just makin' my second slide because that's just the kind of second slide makin' man I am.

created a branch, created a file and made a commit, and opened a pull request.  Now confirming the merge

created a branch, created a file and made a commit, and opened a pull request - now time to merge


Documentation Issue: AuthenticatedClient.getCoinbaseAccounts does not exist.

Hey Coinbase Team,
It looks like your documentation and library might be out of sync. I don't see a getCoinbaseAccounts function on AuthenticatedClient.

This was added in #89, which hasn't been published on npm.


ERDDAP incorrectly encodes ISO8859 characters above 0xa1

Describe the bug
ERDDAP incorrectly encodes characters from the upper half of the ISO-8859-1 table  (à á â ã ä å æ ç è é ê ë ì etc.)
To Reproduce
See notebook https://github.com/callumrollo/erddap-troubleshoot/blob/main/fix_iso8859_characters.ipynb

Generate characters from  ISO-8859-1
Add them in an ERDDAP dataset
Download that to your compute https://erddap.observations.voiceoftheocean.org/erddap/tabledap/experiment_characters.csv?characters"
Or go direct to the html rendering https://erddap.observations.voiceoftheocean.org/erddap/tabledap/experiment_characters.htmlTable?row%2Ccharacters
See mangled characters

Expected behavior
Expect ERDDAP to reproduce  ISO-8859-1 characters with the expected 8 bit codepoints, as described in the table here https://en.wikipedia.org/wiki/ISO/IEC_8859-1#Code_page_layout
Server
https://erddap.observations.voiceoftheocean.org/erddap/
v2.23 via axiom Docker image
Desktop (please complete the following information):
Firefox on Ubuntu 24.04
Additional context
Some discussion on the Google users group https://groups.google.com/g/erddap/c/ObibS-gd7S0
Reproducible notebook example at https://github.com/callumrollo/erddap-troubleshoot/

I still need to investigate this, but it's possible one or more ErrorProne checks (currently disabled) could help pinpoint problem spots in the code. In particular DefaultCharset which is currently disabled in the pom).
I did already update some charset related code (when I enabled the StringCharset ErrorProne check), though I don't believe it would have fixed this (just worth noting in case the issue doesn't reproduce at ERDDAP head).

Potentially related to #87 as highlighted by @kutoso. Though that issue is centered around nccsv export, rather than csv export, both highlight problems with the encoding of non-ASCII characters by ERDDAP

@callumrollo I tried downloading the test_chars.csv from the VOTO server files
As far as I can tell that file is using the UTF-8 character encoding. If I indicate the character encoding for the dataset is UTF-8 it seems to be read properly.
Looking at the sample file you sent to the Google group (https://erddap.observations.voiceoftheocean.org/erddap/files/meta_ballast/ballast.csv), it also seems to be using UTF-8 (or at least my editor parses it properly with UTF-8 encoding, and has weird characters if I tell it to use ISO-8859-1).
Can you try changing the charset for those datasets in your datasets.xml file to UTF-8?
If that's not the issue can you send me the raw files you are having trouble with?

Hi Chris,
Thanks for investigating this. Completely my fault, setting the charset to UTF-8 fixes this issue. I had tested with UTF-8 but must have failed to refresh the dataset on ERDDAP when I did. It's now working https://erddap.observations.voiceoftheocean.org/erddap/tabledap/experiment_characters_utf8.html
I'll leave both test datasets up for posterity and add <charset>UTF-8</charset> to all our datasets.
Thanks again


✨  Add configurable CRDPattern field for manager

What this PR does / why we need it:
This PR allows for CRDPattern to be configurable in deployment customization. This is to allow for installing additional CRDs through the ASO deployment.
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #

I'm a bit confused on how to add a conversion function for CRDPattern. @Fedosin @alexander-demicev is there an example on how to do this? I tried adding something like this to the conversion funcs which didn't seem to work: https://github.com/willie-yao/cluster-api-operator/blob/upstream-install-aso-crds/api/v1alpha1/provider_conversion.go#L48

@willie-yao You can find an example here https://github.com/kubernetes-sigs/cluster-api-provider-aws/pull/4228/files, this PR added a new field to API and conversion to older versions

@willie-yao This change is too specific to capz. What do you think about making it more generic? Can we introduce a new field to customize additional deployments that come with providers? I think something like AdditionalDeployments might work, where we can store the deployment names to customize and DeploymentSpec structure to apply these customizations. Do you think it makes sense?
I can see that in the future there might be more providers like CAPZ with more than one Deployment so it might be better to try to fix the problem in a bigger scope.

@alexander-demicev That is a great idea. I did notice that this may be too specific to CAPZ to be implemented like this. I'll work on adding a field like AdditionalDeployments. Thanks for the suggestion!

/retest

PR looks good, just one small comment

/retest

Looks like there's a problem with the E2E test output. Will be looking into this.

The hyphen in --crd-pattern messed up the test helm command, and since we're just testing if something can be set in the additionalDeployments rather than a specific field, I removed that field.

Actually it looks like the error is coming from the recursivePrinter: https://github.com/willie-yao/cluster-api-operator/blob/25328eb918edd7eb4b2e79cf10ab73cf0ca4f9e1/hack/charts/cluster-api-operator/templates/infra.yaml#L1
I'm not sure how to adjust that function to allow array values to be passed inline. When specifying container customizations for additionalDeployments, using a values file works. Do we have to add support for setting this inline?

I went ahead and removed the test case from helm_test.go due to the complicated nature of setting additionalDeployments via inline --set. If this is something we should support, I'll look into another way to scaffold out the additional customizations.

@willie-yao We can look into setting additionalDeployments in tests in a follow-up PR


Support python versioning

This depends on https://github.com/chevah/python-distribution/issues/3 as first we need to get a meaningful python versioning scheme.
once this is implemented paver.conf could contains something like this:
PYTHON='2.7.8.chevah1'

and paver.sh deps will update the python binary distribution if an older version is present.
with the new python-package only core python is updated, pycrytpo / pyopenssl / pysqlite will remain at the old version and will not be downloaded

implemented with latest paver.sh


CDS-87266-Added all details reg the Approval step in Platform docs and added the relevant link in the same topic in CD docs

Thanks for contributing to the Harness Developer Hub! Our code owners will review your submission.
https://harness.atlassian.net/browse/CDS-87266

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://663c5e1dc30aca5f49a2c70c--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://663dc2e5b85bf5bfddaff636--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://664c4b4d7197f406f0e826f4--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://664c579c06f8a31a6c5bdfbf--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://664c5837ea9f7572d0512cff--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://664c590333bf64af62c784e8--harness-developer.netlify.app


add hostname configuration instructions to documentation

This was accidentally omitted, so generated links incorrectly point back at demi.

Committed a change that makes the default base URL http://localhost:8888/ and added a section in the installation instructions for configuring the base URL with the fqdn of the host.


Add translation support for malagasy langage from Madagascar

[x]  Add mg.txt translation
[x]  Add mg-help.txt to translate help file

Very good! Could you please translate translation.py too? So that we have the messages in Malagasy too?

Thanks a lot! I've merged and deployed it. Please test.


bug: vtsls missing workspace symbols

Did you check docs and existing issues?

[X] I have read all the LazyVim docs
[X] I have searched the existing issues of LazyVim
[X] I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)
v0.11.0-dev
Operating system/version
Windows 11, WSL Ubuntu 22.04
Describe the bug
Missing symbols using LSP Dynamic Workspace Symbols (Telescope) search when using vtsls from LazyVim Extras Typescript. Was able to get expected behavior by disabling LazyVim Extras Typescript and setting my own lspconfig for tsserver.
Steps To Reproduce

Open ts file in ts project with nvim. (small repro repo: https://github.com/jamgam/tslsp-test)
<leader>sS or run :lua require("telescope.builtin").lsp_dynamic_workspace_symbols().
Observe that most symbols are missing.

Expected Behavior
I should see all symbols in my workspace like when using tsserver.
Repro

not really a LazyVim issue is it?
File an issue at the vtsls repo, if this is really broken.

Makes sense. Wanted to bring it up since a recent lazyvim release changed the typescript lsp to vtsls.


Blasterror in fcq.

Out of 17 assemblys CE got to this step 4 times. 12 died with the following error message:
[scr] Failed to align minimum amount of reads (10000) to reference clusters
3 of the 4 that reached that step succeded, but one died with the following error message:
[19-04-14 16:58:23] [PipeWrap] Running 'fcg': /opt/chloroExtractor/bin/find_cyclic_graph.pl --in ass/assembly_graph.fastg --blastdb /opt/chloroExtractor/bin//../data/cds.nr98.fa --out fcg.fa
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = "en_IE:en",
        LC_ALL = (unset),
        LANG = "en_DK.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
[19-04-14 16:58:23] [fcg] Found 100 different nodes with 41455 bp total sequence length and 6 digraph information packages
[19-04-14 16:58:23] [fcg] Found 6 weakly connected components
[Sun Apr 14 16:58:23 2019] WCC:   0%
[Sun Apr 14 16:58:23 2019] WCC:   0%
[Sun Apr 14 16:58:23 2019] WCC:  16%
[Sun Apr 14 16:58:23 2019] WCC:  33%
[Sun Apr 14 16:58:23 2019] WCC:  50%
[Sun Apr 14 16:58:23 2019] WCC:  66%
[Sun Apr 14 16:58:23 2019] WCC:  83%
[Sun Apr 14 16:58:23 2019] WCC: 100%
[19-04-14 16:58:23] [fcg] No single circular chloroplast was found. Searching for partial hits...
Warning: [tblastx] Query is Empty!
[19-04-14 16:58:23] [fcg] Found 0 partial chloroplast sequences

Can you provide the name to the input file? @Joyvalley


Update global travel advice callout to reflect 4th July updates

As per request from FCO.

Time to start booking holidays!


Error with static popup

Version : 7.18
no other addons active ...
Message: Interface\AddOns\KkthnxUI\Core\StaticPopups.lua:249: attempt to call method 'SetPoint' (a nil value)
Time: 04/29/18 16:40:35
Count: 1
Stack: Interface\AddOns\KkthnxUI\Core\StaticPopups.lua:249: attempt to call method 'SetPoint' (a nil value)
Interface\SharedXML\SharedBasicControls.lua:208: in function <Interface\SharedXML\SharedBasicControls.lua:207>
[C]: in function SetPoint' Interface\AddOns\KkthnxUI\Core\StaticPopups.lua:249: in function <Interface\AddOns\KkthnxUI\Core\StaticPopups.lua:243> (tail call): ? [C]: in function StaticPopup_SetUpPosition'
Interface\FrameXML\StaticPopup.lua:4378: in function <Interface\FrameXML\StaticPopup.lua:4023>
[C]: ?
[C]: in function `StaticPopup_Show'
Interface\FrameXML\UIParent.lua:1122: in function <Interface\FrameXML\UIParent.lua:1011>
Locals: errorMessage = "Interface\AddOns\KkthnxUI\Core\StaticPopups.lua:249: attempt to call method 'SetPoint' (a nil value)"
DisplayMessageInternal =  defined @Interface\SharedXML\SharedBasicControls.lua:191
MESSAGE_TYPE_ERROR = 0

Nothing to go on here, you should've used the provided issue template and not just copypasted the bug text with no more info. When did this happen? Was it as a result of you clicking something, or did it just appear out of the blue? Was it on logon? Can you reproduce it?
Description

Version Number

Steps to Reproduce

Step 1
Step 2
Step 3
Step 4

Expected Behavior

Actual Behavior

It occured when being killed , rezzing or when you activate addons when using like world quest group finder

I can reproduce this on logout and click on cancel logout.

Fixed https://github.com/Kkthnx-WoW/KkthnxUI/commit/b9419559784fb0ffbc3b8d2dd72ae3ed0fab7e23


Saving custom model with keras.layers.flatten raised some issues

When I made a custom model by adding Flatten layer onto ResNet and saved the model by
keras.models.save_model(model, "path")
, I got the following error
File ~/anaconda3/lib/python3.10/site-packages/keras/src/layers/reshaping/flatten.py:72, in Flatten.compute_output_spec(self, inputs)
     71 def compute_output_spec(self, inputs):
---> 72     output_shape = self.compute_output_shape(inputs.shape)
     73     return KerasTensor(
     74         shape=output_shape, dtype=inputs.dtype, sparse=inputs.sparse
     75     )

AttributeError: Exception encountered when calling Flatten.call().

'list' object has no attribute 'shape'

Arguments received by Flatten.call():
  • args=(['<KerasTensor shape=(10, 15, 20, 2048), dtype=float32, sparse=False, name=keras_tensor_1070>'],)
  • kwargs=<class 'inspect._empty'>

, where the type of parameter "inputs" is supposed to be  but was [] actually.
I could solve this issue by changing "compute_output_spec" function in "File ~/anaconda3/lib/python3.10/site-packages/keras/src/layers/reshaping/flatten.py" into
def compute_output_spec(self, inputs):
        #print(type(inputs), type(inputs[0]))
        if type(inputs)==list:
            output_shape = self.compute_output_shape(inputs[0].shape)
            return KerasTensor(
                shape=output_shape, dtype=inputs[0].dtype, sparse=inputs[0].sparse
            )

        else:
            output_shape = self.compute_output_shape(inputs.shape)
            return KerasTensor(
                shape=output_shape, dtype=inputs.dtype, sparse=inputs.sparse
            )

However I got same sort of error at function "call" in the same file when loading the model. In this error, on the other hand, the type of parameter "inputs" was
[Traced<ShapedArray(float32[1,15,20,2048])>with<DynamicJaxprTrace(level=1/0)>]
, which I found difficult to fix by myself since it uses new backend.
I hope this error will be fixed.

Thanks for raising this issue.
The reason you are getting this error is, functional model gives a list of outputs.  And flatten layer doesn't take a list of tensors.  So if you modify your code to keras.layers.Flatten()(model.outputs[0]), it would work fine.  Please re-open if it doesn't resolve the issue.

Thank you for your kind reply.
Actually, I figured out the cause of the error and it was because I was using preprocess_input function not from keras.applications.resnet but from tensorflow.keras.applications.resnet50 although I made my model with keras(not tensorflow.keras). The error came not to come out after I fixed that point.
Thank you anyway.

Thanks for raising this issue. The reason you are getting this error is, functional model gives a list of outputs. And flatten layer doesn't take a list of tensors. So if you modify your code to keras.layers.Flatten()(model.outputs[0]), it would work fine. Please re-open if it doesn't resolve the issue.

I have similar issue , below is model build,
Build the model on top of the base model
model = Sequential([
base_model,
Flatten(),
Dense(256, activation='relu'),
Dropout(0.5),
Dense(num_classes, activation='softmax')
])
Could plz help me to sort this out

Thanks for raising this issue. The reason you are getting this error is, functional model gives a list of outputs. And flatten layer doesn't take a list of tensors. So if you modify your code to keras.layers.Flatten()(model.outputs[0]), it would work fine. Please re-open if it doesn't resolve the issue.

same issue, with the Sequential modeling, the Flatten layer are casing by the loading model;
should it be the Sequential Model Design issue, or the SaveModel load_model issue ?
AttributeError: Exception encountered when calling Flatten.call().

'list' object has no attribute 'shape'

Arguments received by Flatten.call():
  • args=(['<KerasTensor shape=(None, 2048), dtype=float32, sparse=False, name=keras_tensor_9330>'],)
  • kwargs=<class 'inspect._empty'>

Same issue for my code:
AttributeError: Exception encountered when calling Flatten.call().

'list' object has no attribute 'shape'

Arguments received by Flatten.call():
  • args=(['<KerasTensor shape=(None, 2048), dtype=float32, sparse=False, name=keras_tensor_367>'],)
  • kwargs=<class 'inspect._empty'>

@ValentinMaftei , Could you please provide the code or open a new issue with the reproducible code to verify the bug from our side. Thank you.

@ValentinMaftei , Could you please provide the code or open a new issue with the reproducible code to verify the bug from our side. Thank you.

Here i create the model:
`model = createModel()
hist = model.fit(trainData, epochs=10, validation_data=valData,
                 callbacks=[tensorboardCallback])

model.save('resnet50Epoch10_v2.keras')`

For image preprocessing:
`    train_datagen = ImageDataGenerator(dtype = 'float32', preprocessing_function=keras.applications.resnet.preprocess_input)
val_datagen = ImageDataGenerator(dtype = 'float32', preprocessing_function=keras.applications.resnet.preprocess_input)`

Here is the model:
def createModel():
    model = Sequential()

    pretrained_model = keras.applications.ResNet50(
        input_shape=(imgDataWidth, imgDataHeight, 3),
        include_top=False,
        weights='imagenet',
        pooling='avg',
        classes=4)

    for layer in pretrained_model.layers:
        layer.trainable = False

    model.add(pretrained_model)
    model.add(Flatten())
    model.add(Dense(1024, activation='relu'))
    model.add(Dropout(0.4))
    model.add(Dense(4, activation='softmax'))

    model.compile(optimizer=Adam(learning_rate=0.0001), loss='categorical_crossentropy', metrics=['accuracy'])

    return model

I get the error when i want to predict for only one image.

@ValentinMaftei , Could you please provide sample toy example with sample input data and all the necessary details to run the code and debug. Preferably colab file.


Add a parameter to show/hide horizontal scrollbar

Thanks for the contribution! That would be a useful thing to expose.
Although I have some concerns regarding the public API suggested. I suspect one might want to customize the style of both horizontal and vertical scrollbars as well as disable them outright. If that's the case, the something like TableScrollbarStyle class which would encapsulate styling parameters (such as interactive, thumbVisibility, thickness, etc.) together with visible parameter might be in order. Exposing attribute suggested in the public API would limit this option. With that said, I'd be ok if the only property of this class for now would be visible boolean.
Another consern is the default scrollPadding values which right now are hardcoded to leave the space for this specific configuration of scrollbars on every platform. This is necessary to allow the content to scroll out from underneath the scrollbars. Hardcoding all the values for each platform seems like a dumb solution but I was unable to come up with anything better at the time. The point is that all scrollbar customization options (including its removal) should somehow reflect on the default values of the scrollPadding.
Another consern is that, afaik, depending on the platform, Flutter will add a scrollbar implicitly if one is not created explicitly. This is not one would want when disabling a scrollbar. Also, I remember a problem with this specific confguration of nested Scrollables, where the implicit interactive scrollbar on desktop was losing track of the thing it was supposed to scroll on interration (with no controller explicitly passed to it) and throwing exceptions instead.
If you could address these conserns I'd be more than happy to accept this PR. Let me know if you have any questions.


Margin if no search bar

The margin on the right needs to always match the margin on the left. Please add padding between end of "sign out" and end of page.

Found the problem - this is just because the demo page was using a div to fake the look of the header. I'll update it to use a real header.


Drop dependency on typing_extensions

Since it was only being used for TypedDict, which was added in Python 3.8 and dj-database-url v2.3.0+ only supports Python 3.9+.
See:
https://docs.python.org/3.12/library/typing.html#typing.TypedDict
https://github.com/jazzband/dj-database-url/blob/master/CHANGELOG.md#v230-2024-10-23

Thank you for the review/merge! :-)


Update the game over message

Update the game over message so people know how to play again!

Some comment


Cache helper does not work UWP apps

I was super excited to try this out instead of doing my own serialization for my UWP app.
But it doesn't work due to code here:
https://github.com/AzureAD/microsoft-authentication-extensions-for-dotnet/blob/c23dd2c211f88143b583a3dd69e50cc55b8c7e43/src/Shared/SharedUtilities.cs
As it is trying to retrieve information about the OS en
Exception thrown: 'System.PlatformNotSupportedException' in System.Diagnostics.Process.dll
Retrieving information about local processes is not supported on this platform.
The documentation here:
https://docs.microsoft.com/en-us/azure/active-directory/develop/msal-net-token-cache-serialization
Isn't very clear about serialization for UWP apps.
It mentions "in-memory" followed "serialization by default". Does that mean that I don't need to serialize to disk for UWP apps (mine is running on a non-mobile platform).
That documentation also states that custom serialization isn't available for UWP, which is odd, because that's precisely what I'm currently doing :)

@GabeDeBacker : this extension library is mean for desktop applications (think, console, WPF, Windows.Forms). We have not tested it with UWP.

Yeah, we haven't tested on UWP. This is likely some obscure API that is available in netstandard but not in UWP ...
I am curious though, why would you need this on UWP? MSAL uses a DPAPI to store encrypted date in a file (or you can define your own serialization which is what you seem to be doing). This library does exactly what MSAL does - uses DPAPI + file on Windows.
I think the value proposition of this library is more around:

token cache encryption on Mac and Linux as well as Windows (not interesting for UWP)
scenarios where multiple apps share the same token cache (I doubt this would work on UWP out of the box, since UWP is super locked down)


ListRun() in threads.runs.listRunSteps() may be nullable in some cases

ListRun() contains non-nullable fields, like firstId or lastId.
But when you run your Run, first call after polling may have queued status and firstId == null and lastId == null.

@yevgeniy-dadonov thank you i fix it.


Outdated RFC reference

The new RFC for JSON is RFC7159, not RFC4627 anymore. Most notable change is that the JSON root can be any value, not just limited to the array or object types.

This should be fixed by deprecating JSON_DECODE_ANY making it the default behavior.


Converted ipynb files to py files to extract dependency - Issue #3

The code now checks for files ending with the .ipynb extension along with the original extension specified.
Implemented .ipynb to .py conversion. A new function convert_ipynb_to_py() is included. This function uses the nbformat library (which has been included) to read the code cells from the .ipynb file and write them to a newly created .py file.
The converted .py file is added to the list of files to be processed for requirement extraction.
[] Closes Issue #3

Hi @Aftabby , thanks for the contribution. I found a few problems while testing the PR in this repo that contains a ipynb file: https://github.com/Ogarantia/tensorflow-attention.git

The ipynb there has an iPython command whose syntax is illegal in Python scripts: !pip install "tensorflow-text==2.8.*". This line also appears in the converted file and miniogre can't really pull the imports. Another iPython-only command that should be removed is %% time.
The created files (.py) should be removed after the generation of the requirements. This is because these files didn't exist in the original repo, and we shouldn't pollute it by duplicating the contents of the file (only the .ipynb should be kept).

I didn't dig into it too much, but there might be a few ideas here: https://nbconvert.readthedocs.io/en/latest/nbconvert_library.html
Or even maybe use subprocess to call nbconvert? See this: https://nbconvert.readthedocs.io/en/latest/usage.html

@Aftabby -- any updates? Let us know if you need help.

@wilderlopes Thank you for checking up on that, I am quite unsure how to handle the unique expression like your mentioned ones  !pip install "tensorflow-text==2.8.*" .
Needless to say, I am still at beginner level. So, yes if you could provide some hints that might help me track down the solution.
Thank you for understanding.

Hi @Aftabby. After checking your pull request, I noticed there were some issues that needed fixing. In the process of fixing it, I realized it was better to try a totally new approach, which have been pushed to main (https://github.com/ogre-run/miniogre/commit/88067d9a4bd17a4ba51e99c0cff6d921cc2677a6).
Thus, I am closing this pull request because this solution won't be implemented.


Hello, can't be installed in win7 tf1.4 python3 ?

Hello, can't be installed in win7 tf1.4 python3 ?

Please report issues following the issue template.


Added tests for H I bf & ff opacities and improved documentation

The main purpose of this PR is to introduce tests confirming that the H I bf & H I ff opacities are computed correctly. These tests helped lead me to the bug introduced in PR #11.
For both the free-free and bound-free opacities, I wrote independent implementations based on the approaches described in Gray (2005). Because Gray (2005) both makes slightly different approximations and casts the constants into a completely separate form, I feel that these tests are a relatively robust accuracy check. I added an additional minor testset for the bound-free opacities, checking the validity of our integral approximation.
I additionally created a test comparing the combined H I bf and H I ff opacity values to the tabulated curves from the panels of figure 8.5 from Gray (2005). The updated plots are provided below. As you can see, PR #11 largely reconciled the differences in the curves that I had previously shared. While some discrepancy still remains, I'm not concerned about it all; the individual tests (described in the last paragraph) indicate that there is reasonable agreement. The remaining discrepancy is plausibly described by differences in the approximations, which are:

Gray (2005) suggests that the summation in the bound-free opacity can be replaced by an integral at smaller n values than Kurucz (1970); note that above ~4.45 microns Kurucz (1970)'s approach uses in a comparable or potentially more aggressive manner. This helps explain why our approach always gives smaller values.
Gray (2005) suggests the use of a much older/analytic approximations for both sets of gaunt factors. I think this generally means that their results are less accurate.

If you want a more detailed description about the changes that were made, I would encourage you to take a look at the commit messages (they're fairly detailed).
Future Work on Continuum Opacities:
I've still got to fix the H₂⁺ ff and bf opacities, but I'll do that in a separate branch. After I do that, I'll start refactoring the continuum opacities so that we achieve better performance. At this point I think that the dominant continuum opacities are robust enough that we should be able to start generating realistic spectra.
Plotted Opacities:
Panel B (T = 6428 K, Pₑ = 10^1.77 dyne cm⁻²):

Panel C (T = 7715 K, Pₑ = 10^2.50 dyne cm⁻²):

Panel D (T = 11572 K, Pₑ = 10^2.76 dyne cm⁻²):

This is amazingly complete!

Please merge once/if you address the small comments above.


Rename to "Bellboy"

Freckle has some legalities around the naming. It would be unwise to continue
with this as a name for the tool. I would rather have the nanmes that stay
clear of the "Freckle" key word; albeit names like "Freckle Commandline Tool -
FCT" being as descriptive as possible. So I checked what freckles are
associated with, and "Bellboy" came up. ...since this is something which would
be logging my time for me anyways

This would mean changing the following files

config/config.exs
entry file
library folder
keys in the config
…and so on


Update Read_Me with further instructions

Update the existing Read_me with further instructions for installation and usage of the Network_Analysis - also adding images and examples would be great.

I can work on this issue, but I need to understand more about our code and the installation flow

@bhadreshpsavani Great! Which information do you need?
Just to get started some general information:
The repo consists of several folders and files. The "first layer" files are the ones that are most important. Currently network_test.py as well as network_test_class.py are pretty much the same just with the small difference, that network_test_class.py is build up as a class and will be used in future extension. By running both files you will start a network test. You can find the different options in the argument parser. If you run those files they will send ping requests to a server (that you can define) and if the ping time droppes below a specific threshold (which you can set) it will automatically test the current speed of your internet connection. Both observations will be stored in 2 sepperate CSV files which location you can set in the arguments. Default is the Data dirctory.
Visuals.py is a class that can automatically generate plots (which are also produced in the notebook) and export them to the folder webpage/figures. If figures dosen't exist in your clone - do not worry - it will be build automatically.
Analytics.ipynb is a notebook where Data wrangling and visualization is made. It is used to analyze the statistics that have been catched during running the network_test.py /network_test_class.py.
For installation the requirements.txt musst be installed via pip. Make sure that everything is run as sudo when you are on Linux because this is the only way to get access to the IP Layer on Linux.
If you've got further questions - feel free to ask!

@bhadreshpsavani I saw on your profile that you are also firm with ML - if you like to feel free to make a notebook concerning Feature Generation and some unsupervised learning based on the 2 CSV files in the Data Directory. (You first have to run the network_test.py in order to generate them)
the corresponding Issue would be #7

Hi. I can try to create good README with instructions for users, program desription and installation guide. Also I see that you need some updates in your webpage. If you will explain me what do you want I can create css file or something.
During this process I will get familiar with your code and maybe will make some code pull request. My diploma work was kind of network pinger.
And this is my first steps in open source development...

Hello @2Max4
I would love to apply machine learning in the issue #7
In India, we have traditional festivals this week i might not get much time, i will start working by monday on both of the above issues
Thanks you for the in depth explanation about Repository.

@bhadreshqsavani awesome! Enjoy your festivals! Maybe it is better if you Fokus in ml and @Guo2006 creates the read me related stuff! I think this may be more effective!
@Guo2006 could you start with the read me?

Hi @2Max4,
I was going through the code and created a very basic version of README for my understanding. The same README could be elaborated forward. Adding pull request for the same.PR #39.
I also added a test script in the same.

Already merged it - will add more information asap