Impact of text length on identified entities

We've been playing around with Entity Fishing on a couple of sample scientific texts and have noticed that the results seem to morph in non-expected ways depending on the amount of the text that is provided to process. We've tried to  modify the text provided in our requests in various ways to try and identify the triggering condition(s) with no real success
Is this changing of results expected behavior or are there recommended guidance on the optimal amount of material to submit (paragraphs are better than documents, etc.)?
Here is one example of what we are seeing when submitting to the demo server from one of our test open access journal articles.
========
Submitting a single sentence from the article (Note: This will accurately disambiguate ASPERA and PLASMA among others)
{
    "text": "The observations presented were those made of the Venusian ionospheric plasma by the ASPERA-4 experiment onboard the Venus Express spacecraft, and which constitute the first extensive in-situ measurements of the plasma near solar minimum.",
    "shortText": "",
    "termVector": [],
    "language": {
        "lang": "en"
    },
    "entities": [],
    "mentions": [
       "ner",
        "wikipedia"
    ],
    "nbest": false,
    "sentence": false
}

Submitting the previous sentence with other sentences from the document that have a variation of one of the entities (ASPERA, PLASMA, and now PLASMA DENSITIES are all correctly disambiguated)
{
     "text": "The observations presented were those made of the Venusian ionospheric plasma by the ASPERA-4 experiment onboard the Venus Express spacecraft, and which constitute the first extensive in-situ measurements of the plasma near solar minimum\nThese PVO observations covered all local time sectors.\nIn the nightside ionosphere they showed that precipitating electrons could contribute only ∼25% of the plasma densities observed and that changes in ionospheric densities were much more variable than, and not correlated with, changes in the flux of precipitating electrons (Spenner et al., 1981).",
    "shortText": "",
    "termVector": [],
    "language": {
        "lang": "en"
    },
    "entities": [],
    "mentions": [
       "ner",
        "wikipedia"
    ],
    "nbest": false,
    "sentence": false
}

Finally, submitting the entire document - (PLASMA DENSITIES correctly disambiguated, PLASMA occurrences are no longer recognized or disambiguated, and ASPERA is identified as an ORGANIZATION entity but not disambiguated)
{
      "text": "The transterminator ion flow at Venus at solar minimum\n\nAbstract\nThe transterminator ion flow in the Venusian ionosphere is observed at solar minimum for the first time.\nSuch a flow, which transports ions from the day to the nightside, has been observed previously around solar maximum.\nAt solar minimum this transport process is severely inhibited by the lower altitude of the ionopause.\nThe observations presented were those made of the Venusian ionospheric plasma by the ASPERA-4 experiment onboard the Venus Express spacecraft, and which constitute the first extensive in-situ measurements of the plasma near solar minimum.\nObservations near the terminator of the energies of ions of ionospheric origin showed asymmetry between the noon and midnight sectors, which indicated an antisunward ion flow with a velocity of (2.5±1.5)kms-1.\nIt is suggested that this ion flow contributes to maintaining the nightside ionosphere near the terminator region at solar minimum.\nThe interpretation of the result was reinforced by observed asymmetries in the ion number counts.\nThe observed dawn-dusk asymmetry was consistent with a nightward transport of ions while the noon-midnight observations indicated that the flow was highly variable but could contribute to the maintenance of the nightside ionosphere.\nHighlights\n► The transterminator ion flow in the Venusian ionosphere is observed at solar minimum.\n► This flow has a velocity of (2.5±1.5)kms-1.\n► The occurrence of this flow is highly variable, but can be a significant source of the nightside ionosphere.\n\nIntroduction\nThe nightside ionosphere of Venus has a dynamic and complex structure (Brace et al., 1979).\nTo date the most extensive set of in situ observations of the ionospheric plasma were obtained by Pioneer Venus Orbiter (PVO).\nAlthough the PVO mission covered an entire solar cycle the ionospheric measurements were largely restricted to a limited period close to solar maximum between 1978 and 1980 when the PVO periapsis was at a sufficiently low altitude to allow sampling of the ionosphere.\nThe solar flux during this period was about 200 solar flux units (sfu).\nThese PVO observations covered all local time sectors.\nIn the nightside ionosphere they showed that precipitating electrons could contribute only ∼25% of the plasma densities observed and that changes in ionospheric densities were much more variable than, and not correlated with, changes in the flux of precipitating electrons (Spenner et al., 1981).\nObservations of the flux of atomic oxygen ions across the terminator from the day to nightside showed that this ion flux was sufficient to explain the observed ion densities in the nightside ionosphere at solar maximum (Knudsen et al., 1980).\nThe ions were assumed to follow ballistic trajectories and theoretical calculations predicted that 80% of the ions that crossed the terminator had recombined with electrons before they reached a solar zenith angle (SZA) of 110°.\nOnly those ions that crossed the terminator at the highest altitudes reached the central region of the nightside ionosphere.\nA modelling study by Cravens et al. (1983) predicted that ions which crossed the terminator at altitudes below 500km recombined before reaching a SZA of 120°, whilst ions that crossed the terminator at 876km influenced the entire night sector.\nTaken collectively these results showed that the primary source of the nightside ionosphere was plasma transport from the dayside.\nThe plasma flow from the subsolar region toward the nightside is primarily driven by the day-to-night pressure gradient (Knudsen et al., 1981).\nKnudsen et al. (1982) showed that the flow speed across the terminator was highly variable but was typically several kilometres per second.\nThe average value of the antisunward component of the velocity in the terminator region at solar maximum increased with altitude from a few hundred metres per second at an altitude of 150km to ∼4kms-1 at 800km (Knudsen and Miller, 1992).\nThe altitude of the ionopause in the terminator region played an important role in the total number of ions transported from the day to the nightside.\nIts altitude in this region was variable (Elphic et al., 1980) but was typically around 1000km (Brace et al., 1983).\nThis variability was attributed to changes in the solar EUV flux and the solar wind dynamic pressure, the balance of which altered the ionopause altitude (Knudsen and Miller, 1992).\nAs the ionopause moved to lower altitudes the total number of ions transported antisunward was reduced (Knudsen et al., 1981).\nTheoretical calculations by Brace et al. (1995) showed that the transterminator flow could transport more ions antisunward than were required to maintain the nightside ionosphere and it was suggested that some of these ions might be lost to the solar wind.\nLimited in situ ionospheric observations aboard PVO were made in the pre-dawn sector at low latitudes in 1992 in the declining phase of solar cycle 22 under conditions of moderate solar flux (∼120sfu).\nThe observed ion densities in this sector were significantly larger than those that would be expected in the absence of an antisunward ion flow.\nThis suggested that ion transport was significant in this sector (Brannon et al., 1993).\nThe PVO observations showed that the total transterminator flux was 23% of that at solar maximum and that the largest reductions in the number of ions transported antisunward occurred at the highest altitudes (Spenner et al., 1995).\nThe PVO mission did not include in situ observations of the Venusian ionosphere around solar minimum, however the behaviour of the ionopause was inferred from PVO radio occultation profiles, for which the temporal data coverage was less extensive than for the in situ measurements.\nThe ionopause was at significantly lower altitudes at solar minimum than at solar maximum, typically between 200km and 300km for all SZA (Kliore and Luhmann, 1991).\nThe radio occultation profiles from PVO also showed that the transport process was severely inhibited (Knudsen et al., 1987).\nRadio occultation profiles from Venera 9 and 10 observed the ionopause at higher altitudes in the terminator region at solar minimum with altitudes between 600km and 800km (Gavrik and Samoznaev, 1987).\nThe Venusian ionosphere exhibited a number of asymmetries between the dawn and dusk sectors.\nBrace et al. (1982) observed that the ionopause was higher on the dawn side than at dusk due to interaction with the solar wind.\nMiller and Knudsen (1987) reported larger antisunward velocities within the ionosphere on the dawn side than on the dusk side above an altitude of 400km, with the pattern reversed below this altitude.\nThe dawn-dusk asymmetry below 400km was largely attributed to photoionisation as plasma in the post-noon sector had been exposed to sunlight for longer than plasma in the pre-noon sector.\nThe plasma flow from the dayside to the nightside was driven by the day-to-night pressure gradient, with the higher plasma densities in the post-noon sector enhancing the nightward transport of ions on the dusk side.\nThe super-rotation of the neutral atmosphere also enhanced the ion flow on the dusk side and reduced the flow on the dawn side due to collisional interactions between the ions and the neutral species.\nA subsequent modelling study at the altitude of the peak density in the ionosphere (∼140km) showed that differences in the thermospheric composition between the dawn and dusk sides may also cause asymmetries in the ionosphere at these altitudes due to changes in the dominant chemical reactions (Fox and Kasprzak, 2007).\nBetween August 2008 and October 2009 Venus Express (VEX) was in an orbit with periapsis near 86°N and an altitude between 185km and 215km with about 10min spent in the ionosphere during each orbit.\nTaken collectively over many orbits the in situ ionospheric measurements cover all local time sectors, with each orbit sampling the terminator region at polar latitudes.\nIn the current study these observations are used to determine the plasma distribution near the terminator and to show that the transport process contributes to the maintenance of the nightside ionosphere close to solar minimum.\nInstrumentation\nVenus EXpress (VEX) is the first European mission to Venus (Titov et al., 2006).\nThe VEX spacecraft was inserted into a near polar orbit in April 2006 and so every orbit sampled the terminator region at polar latitudes.\nThe Analyser of Space Plasmas and Energetic Atoms (ASPERA-4) package on VEX contains an ELectron Spectrometer (ELS), an Ion Mass Analyzer (IMA), a Neutral Particle Detector (NPD) and a Neutral Particle Imager (NPI) (Barabash et al., 2007).\nIn August 2008 periapsis was lowered from an altitude of around 300km to 185km, allowing the spacecraft to sample deeper into the ionosphere.\nObservations made using the IMA sensor once this manoeuvre had occurred are of particular interest to the present study.\nThis instrument observes the ion energy per charge, E/q, the mass per charge, m/q, and the arrival direction of each ion as well as the number of ions observed.\nIt has a 360° instantaneous field of view in azimuth and ±45° field of view in elevation in the spacecraft frame of reference and an energy range of 10eV-30keV.\nThe standard observing mode used during the period considered in this study was a scan in decreasing energy through 96 equal logarithmic steps, observing for 250ms at each.\nThese measurements were made at all azimuths simultaneously at a given elevation.\nThe elevation angle was varied through eight positions, which gave a total cycle time of 192s.\nObservations\nData subsequent to the lowering of the periapsis of VEX were considered for the study.\nOne Venus year of data were selected between 4th August 2008 and 17th March 2009 allowing the spacecraft to sample all local time sectors twice as it transited these sectors at high latitudes in opposite directions half a Venusian year apart.\nPeriapsis was at 86°N during this interval.\nThe ion counts as a function of energy observed by the IMA during a spacecraft transit between 04:30 UT and 06:30 UT on 9th August 2008 are shown on a logarithmic scale in the upper panel of Fig. 1.\nThe ion counts as a function of mass channel number are shown in the lower panel of Fig. 1 with lower channel numbers corresponding to higher mass ions (Barabash et al., 2007).\nThese data from 9th August 2008 are considered as an example to show how data from the entire year were selected and processed.\nThe data in the lower panel show two clear ion populations; one with a higher ion mass per unit charge (lower mass channel number) observed between 05:28 UT and 05:47 UT and one with a lower ion mass per unit charge (higher mass channel number) observed before and after this time interval.\nPrior to 04:46 UT and after 06:03 UT the IMA observed ions with energies of some 300-800eV (Fig. 1, upper panel) with a low mass to charge ratio (high channel number in Fig. 1, lower panel) indicating that the spacecraft was in the solar wind.\nIn the intervals from 04:46 UT to 05:28 UT and 05:47 UT to 06:03 UT the IMA sensor observed ions over a larger range of energies than observed in the solar wind, from some 200eV to 1keV with mass to charge ratios similar to that observed in the solar wind.\nThese data suggested that the spacecraft was in the shocked solar wind, downstream of the bow shock.\nThe observations closest to periapsis, between 05:28 UT and 05:47 UT, showed ions at energies below some 50eV with higher masses than those observed in the solar wind.\nThese low energy ions were interpreted as being of planetary origin.\nInspection of the datasets from a large number of orbits showed that it was convenient to locate the Ion Composition Boundary (ICB), which marks the transition between the shocked solar wind and the planetary plasma (e.g. Martinecz et al., 2008), by considering the mass channel number at which the largest number of ions was observed in each 192s cycle.\nData from times at which the mass channel number of the maximum ion count was 15 or less were taken to correspond to altitudes below the ICB.\nThese data were then considered for further analysis.\nFor example, in the data set for 9th August 2008 shown in Fig. 1, the data between 05:28 UT and 05:47 UT were interpreted as being from inside the ICB.\nThese data are shown within the pink box in Fig. 1, and it was these data that were considered for further analysis in this particular example.\nThe spacecraft velocity at periapsis (∼200km) was ∼10kms-1, which was larger than the ion velocities of ∼3kms-1 observed by PVO at these altitudes (Knudsen and Miller, 1992).\nTo ensure that the ions were detected, observations were only considered if the spacecraft ram direction was within the field-of-view of the IMA.\nThis selection criterion meant that observations were only considered when the spacecraft attitude was suitable for observing the ions.\nThe IMA observed in the ram direction for all, or part, of the time when VEX was within the ionosphere on 136 orbits, and data from this sub-set of orbits (136 orbits out of 226 orbits) was considered for further analysis.\nIn this subset of 136 orbits, ions were observed at eight elevation angles during each cycle of 192s duration.\nFor each cycle of each orbit the ion count at the elevation angle with the maximum ion count was found and considered further.\nUsing the counts from this elevation the next step was to obtain the \"summed ion count\" for the cycle, defined as the total ion count summed over all energy levels below 100eV.\nThus a value of the summed ion count was determined for each cycle.\nThe duration of each complete cycle was 192s, however, the summed ion count corresponded to observations from only one of the eight elevations and only a proportion of the 96 energy levels, with the actual observations at one elevation angle and at energies below 100eV being conducted in 6.5s.\nDuring this time interval the spacecraft moved some 65km (6.5s times the satellite velocity of ∼10kms-1).\nThus the summed ion count was observed over a horizontal distance of some 65km which is approximately 0.01 Rv where Rv is the radius of Venus (6052km).\nThe summed ion counts for all cycles are plotted in Venus Solar Orbital (VSO) coordinates in Fig. 2.\nThe positive x-axis is directed towards the Sun.\nThe positive y-axis is orthogonally directed and opposite to the planetary orbital velocity i.e. towards dawn, which is opposite to the Earth due to the retrograde rotation of Venus.\nThe largest summed ion counts were in the polar region close to periapsis where the spacecraft sampled the lowest altitudes.\nIn this region the spacecraft was in the topside ionosphere, where the ion density decreases with increasing altitude.\nData in Fig. 2 exhibit asymmetries in both the dawn-dusk and noon-midnight directions.\nTo investigate the dawn-dusk asymmetry data were selected from a narrow region aligned with the dawn-dusk axis.\nThis region was centred on the terminator and had a width of 0.4 Rv (the x coordinate was restricted to |x|<0.2 Rv).\nThe observations in this region were then binned into intervals of 0.1 Rv in the dawn-dusk direction (y-direction) near the y=0 axis.\nThe small number of points further from this axis required larger bins and an interval of 0.2 Rv was considered between |y|=0.3 Rv and 0.5 Rv and an interval of 0.25 Rv between |y|=0.5 Rv and 0.75 Rv.\nThe median and quartile values of the ion counts in each bin are plotted in the upper panel of Fig. 3.\nA strong dawn-dusk asymmetry was observed, with the median counts larger on the dusk side than on the dawn side by almost an order of magnitude with median values of ∼6×105 on the dusk side and ∼5×104 around dawn.\nA similar plot for a noon-midnight narrow region is shown in the lower panel of Fig. 3 with a restriction that |y|<0.2 Rv.\nThe observations were binned into intervals of 0.1 Rv between |x|=0.0 Rv and 0.3 Rv, 0.2 Rv between |x|=0.3 Rv and 0.5 Rv, 0.5 Rv between |x|=0.5 Rv and 1.0 Rv, and 1.0 Rv for -0.2 Rv<x<-1.0 Rv.\nThis ensured sufficient numbers of points in each bin.\nA noon-midnight asymmetry is apparent, with larger median summed ion counts ∼3×105 in the noon sector.\nVariability is observed on the dayside where the counts are expected to decrease away from the terminator as the spacecraft moves to higher altitudes and to increase because of a decreasing solar zenith angle.\nThe ion counts decrease rapidly on the midnight side to values of ∼5×104.\nHowever, the upper quartile showed that significant numbers of ions could be present nightward of the terminator (located at x=0) and that these values could be comparable to those on the dayside ionosphere with values as large as ∼8×105 recorded in both the day and night sectors.\nThe summed ion counts considered in the preceding paragraphs were for energies less than 100eV.\nThe energy level within this range at which the largest number of ions occurred during each cycle of 192s was determined.\nFor each cycle, the energy of this level was then corrected for the spacecraft potential using the method of Coates et al. (2008) based on the analysis of the ionospheric photoelectron peaks, and the corrected value considered as the energy representative of the ions at the location of the spacecraft.\nTo investigate ion flow in the terminator region an additional constraint was imposed to restrict observations to within ∼30° latitude of the pole.\nPeriapsis was close to 86°N throughout the study period of one Venus year, and the restriction was done by considering only observations at an altitude of 500km or lower.\nThe resulting data were then divided into four bins depending upon the direction of travel of the spacecraft;•\nSpacecraft travelling essentially from noon-to-midnight (within 45° of this direction);\n•\nSpacecraft travelling essentially from midnight-to-noon (within 45° of this direction);\n•\nSpacecraft travelling essentially from dawn-to-dusk (within 45° of this direction);\n•\nSpacecraft travelling essentially from dusk-to-dawn (within 45° of this direction).\nThe spacecraft velocity at periapsis was essentially constant for all observations, with a mean value of (9.78±0.01)kms-1.\nFor each bin the median value of the observed energy was determined.\nThis was (11±3)eV for the noon-to-midnight bin and (20±4)eV for the midnight-to-noon bin, with the uncertainties set by the upper and lower quartiles.\nThe larger ion energies in the midnight-to-noon bin suggested that these ions had a velocity component that was antiparallel to the spacecraft direction of travel and the smaller values in the noon-to-midnight bin suggested that these ions had a velocity component that was parallel to the spacecraft direction of travel.\nTaken together both of these observations suggest that the ions travelled in the noon-to-midnight direction.\nFor both the dawn-to-dusk and dusk-to-dawn bins the energies were (18±4)eV.\nThe difference in the ion energies of these bins was zero within the error margin, which suggested that there was no net ion flow in this direction.\nDiscussion\nResults have been presented of ion counts and energies measured by the ASPERA-4 experiment onboard the VEX spacecraft as it traversed the Venusian ionosphere at polar latitudes.\nStrict selection criteria were applied to the data to ensure that the measurements used in the study were of ionospheric ions.\nMedian ion energy values near the midnight-noon meridian were larger when the spacecraft traversed from midnight-to-noon than from noon-to-midnight.\nThe larger values of the former case suggested that the ions had a velocity component that was antiparallel to the spacecraft direction of travel, while the smaller values of the noon-to-midnight traversal suggested that the ions had a velocity component parallel to the spacecraft direction of travel.\nThis suggested the nightward transport of the ions at polar latitudes.\nMedian values near the dawn-dusk meridian were identical for traversal from dawn-to-dusk and from dusk-to-dawn within the error margins suggesting that there was no net ion flow in this direction.\nTaken collectively the observed ion energies therefore indicated an ion flow predominantly in the noon-to-midnight direction.\nThe spacecraft velocity near periapsis was essentially the same for all orbits and all directions of travel and so the difference in the ion energy between the midnight-to-noon and noon-to-midnight traversals, (9±7)eV, may be attributed to the flow of ions.\nBy using the same assumption as Knudsen and Miller (1992) that the ions were primarily singly ionised oxygen, and that the measured energy difference was representative kinetic energy of the ions a nightward ion velocity of (2.5±1.5)kms-1 is estimated.\nIt is appreciated that there are substantial uncertainties in this velocity and that the IMA was operating close to the lowest energies it could observe, however it is encouraging that this velocity is in broad agreement with Knudsen and Miller (1992) who reported antisunward ion flows of some ∼3kms-1 at these altitudes.\nA dawn-dusk asymmetry in the plasma distribution of the Venusian ionosphere has been reported by Miller and Knudsen (1987) with larger plasma densities observed in the dusk sector.\nTheir study was conducted at low- and mid-latitudes around solar maximum, and the observation associated with the asymmetry of plasma transport where higher density plasma was drawn antisunward (nightward) from the post-noon sector as a transterminator flow.\nThe dawn-dusk ion asymmetry in the current study (Fig. 3, upper panel) was consistent with their interpretation.\nThe observed ion counts in the noon-midnight plane (Fig. 3, lower panel) suggested that the transterminator flow was highly variable.\nThe median values of the three points immediately sunward of the terminator showed the largest values.\nThe median values fell rapidly nightward of the terminator, as expected in the absence of a plasma source.\nThe lower median value of ∼8×104 on the dayside at 0.4 Rv was a likely consequence of the spacecraft sampling at higher altitudes where the ion densities were expected to be lower.\nIndeed, sunward of 0.5 Rv no data points were recorded.\nThis may be explained by the altitude of the ionopause falling to 200km-300km on the dayside (Kliore and Luhmann, 1991) and the spacecraft sampling above these altitudes when it was located ∼0.3 Rv sunward of the terminator.\nThe upper quartile values varied substantially between adjacent bins.\nUpper quartile values in the nightside at a distance of less than 0.5 Rv from the terminator were similar to, or greater than, the median values on the dayside.\nThis suggested that in a substantial number of cases the ion counts nightward of the terminator were comparable to the values in the dayside ionosphere, although in general the ion counts nightward of the terminator were lower than those observed on the dayside as expected in the absence of a plasma source.\nThis indicated that, at times, a process was operating to maintain the nightside ionosphere although the occurrence of this process was highly variable.\nIn summary the observations of ion energies indicated that a nightward ion flow across the terminator at solar minimum can occur.\nThe ion counts show that such a flow is highly variable but the results indicate that it can contribute to the maintenance of the nightside ionosphere.\nConclusions\nIn situ ion observations made by the ASPREA-4 experiment onboard the Venus Express spacecraft at solar minimum have shown dawn-dusk and noon-midnight asymmetries.\nIon energies observed when the spacecraft trajectory was directed midnight-to-noon were significantly higher than those observed when the trajectory was directed noon-to-midnight.\nThis difference in ion energies suggested an antisunward transterminator flow with a velocity of (2.5±1.5)kms-1.\nIt is suggested that this flow contributes to maintaining the nightside ionosphere near the terminator region at solar minimum.\nThe interpretation of the antisunward flow was reinforced by observed asymmetries in the ion number counts.\nThe dawn-dusk ion asymmetry showed larger numbers of ions on the dusk side than on the dawn side consistent with the previously reported observations of antisunward transterminator flow at solar maximum from PVO.\nFor the noon-midnight asymmetry larger numbers of ions occurred on the dayside and there was substantial variability in the observations of counts on the nightside.\nIn a substantial number of cases the number of ions nightward of the terminator was comparable to the number observed on the dayside.\nIn other cases the number of ions nightward of the terminator was much lower, as expected in the absence of a plasma source.\nThese observations suggested that the transterminator flow was highly variable and, in some cases, did not operate at all.\nAcknowledgements\nThe authors would like to thank the ASPERA-4 team for their extensive work planning, constructing and operating these instruments on the Venus Express spacecraft, and the subsequent dissemination of these data.\nThe assistance of Neville Shane from Mullard Space Science Laboratory, University College London in implementing software tools at Aberystwyth University is gratefully acknowledged.\nFinancial support for this paper was provided by the UK Science and Technology Facilities Council under grant PP/E001157/1.\n\n",
    "shortText": "",
    "termVector": [],
    "language": {
        "lang": "en"
    },
    "entities": [],
    "mentions": [
       "ner",
        "wikipedia"
    ],
    "nbest": false,
    "sentence": false
}

Also worth noting if we tried this simple example, and we do not include the ner mention module, it still tags ASPERA and links it.
{
    "text": "The observations presented were those made of the Venusian IONOSPHERIC plasma by the ASPERA-4 experiment onboard the VENUS EXPRESS SPACECRAFT, and which constitute the first extensive IN-SITU measurements of the plasma near SOLAR MINIMUM.",
    "shortText": "",
    "termVector": [],
    "language": {
        "lang": "en"
    },
    "entities": [],
    "mentions": [
        "wikipedia"
    ],
    "nbest": false,
    "sentence": false
}

Hello @curtkohler !
This is the expected behaviour, the more the tool has text, the more it will use the context to disambiguate it. It actually exploit all the available text - there is no window considered -, so the longer the text, the slower the process will be because of the number of contextual entities to manage at each disambiguation decisions.
It might happen that with more text, the disambiguation get worse, because the weight of a term sometime introduce some unexpected noise and overall the decision trees are less efficient.
The expected input for the text field is a paragraph. You can send a sentence or a few paragraphs, but the disambiguation might be lower quality in the first case (less disambiguation context) and slower in the second case.
For sending a large amount of text, there are two possibilities:

the client segments the text into paragraphs and send each paragraph. Optionally to help the disambiguation, you can send with each paragraph a customization object with relevant global text (e.g. the abstract of a document) or a list of contextual entities to consider (for instance the most frequent entities in the previously processed paragraphs.

send the full text but use the processSentence field to point only a few sentences to process. For this you need first to get the text segmented into sentences by the service for having the right sentence boundary offsets.

If it's a scholar PDF, entity-fishing integrates Grobid and will segment the text already into paragraphs and manage the customization to maintain a global disambiguation context along the whole document (basically it uses the abstract to contextualize then every paragraph of the document).
In the case the text is very short, like for a search query, a phrase, or a super short sentence, the shortText field must be used instead of the text field.

Dear @curtkohler and @antonyscerri
I am coming back to your example, given your questions and some other feedback, I revised the behavior in case of long text. The server now segment automatically the input text into paragraph-like segments and manage a sliding context window. In addition, a document level second pass revisit the other occurrences of terms linked elsewhere in the document. So the results are now much more stable with respect to the length of the text and we don't put anymore on the client/user of the service the burden of segmenting the text and managing the context via successive API call.
To come back to your example, now with the complete text document:
{
      "text": "The transterminator ion flow at Venus at solar minimum\n\nAbstract\nThe transterminator ion flow in the Venusian ionosphere is observed at solar minimum for the first time.\nSuch a flow, which transports ions from the day to the nightside, has been observed previously around solar maximum.\nAt solar minimum this transport process is severely inhibited by the lower altitude of the ionopause.\nThe observations presented were those made of the Venusian ionospheric plasma by the ASPERA-4 experiment onboard the Venus Express spacecraft, and which constitute the first extensive in-situ measurements of the plasma near solar minimum.\nObservations near the terminator of the energies of ions of ionospheric origin showed asymmetry between the noon and midnight sectors, which indicated an antisunward ion flow with a velocity of (2.5±1.5)kms-1.\nIt is suggested that this ion flow contributes to maintaining the nightside ionosphere near the terminator region at solar minimum.\nThe interpretation of the result was reinforced by observed asymmetries in the ion number counts.\nThe observed dawn-dusk asymmetry was consistent with a nightward transport of ions while the noon-midnight observations indicated that the flow was highly variable but could contribute to the maintenance of the nightside ionosphere.\nHighlights\n► The transterminator ion flow in the Venusian ionosphere is observed at solar minimum.\n► This flow has a velocity of (2.5±1.5)kms-1.\n► The occurrence of this flow is highly variable, but can be a significant source of the nightside ionosphere.\n\nIntroduction\nThe nightside ionosphere of Venus has a dynamic and complex structure (Brace et al., 1979).\nTo date the most extensive set of in situ observations of the ionospheric plasma were obtained by Pioneer Venus Orbiter (PVO).\nAlthough the PVO mission covered an entire solar cycle the ionospheric measurements were largely restricted to a limited period close to solar maximum between 1978 and 1980 when the PVO periapsis was at a sufficiently low altitude to allow sampling of the ionosphere.\nThe solar flux during this period was about 200 solar flux units (sfu).\nThese PVO observations covered all local time sectors.\nIn the nightside ionosphere they showed that precipitating electrons could contribute only ∼25% of the plasma densities observed and that changes in ionospheric densities were much more variable than, and not correlated with, changes in the flux of precipitating electrons (Spenner et al., 1981).\nObservations of the flux of atomic oxygen ions across the terminator from the day to nightside showed that this ion flux was sufficient to explain the observed ion densities in the nightside ionosphere at solar maximum (Knudsen et al., 1980).\nThe ions were assumed to follow ballistic trajectories and theoretical calculations predicted that 80% of the ions that crossed the terminator had recombined with electrons before they reached a solar zenith angle (SZA) of 110°.\nOnly those ions that crossed the terminator at the highest altitudes reached the central region of the nightside ionosphere.\nA modelling study by Cravens et al. (1983) predicted that ions which crossed the terminator at altitudes below 500km recombined before reaching a SZA of 120°, whilst ions that crossed the terminator at 876km influenced the entire night sector.\nTaken collectively these results showed that the primary source of the nightside ionosphere was plasma transport from the dayside.\nThe plasma flow from the subsolar region toward the nightside is primarily driven by the day-to-night pressure gradient (Knudsen et al., 1981).\nKnudsen et al. (1982) showed that the flow speed across the terminator was highly variable but was typically several kilometres per second.\nThe average value of the antisunward component of the velocity in the terminator region at solar maximum increased with altitude from a few hundred metres per second at an altitude of 150km to ∼4kms-1 at 800km (Knudsen and Miller, 1992).\nThe altitude of the ionopause in the terminator region played an important role in the total number of ions transported from the day to the nightside.\nIts altitude in this region was variable (Elphic et al., 1980) but was typically around 1000km (Brace et al., 1983).\nThis variability was attributed to changes in the solar EUV flux and the solar wind dynamic pressure, the balance of which altered the ionopause altitude (Knudsen and Miller, 1992).\nAs the ionopause moved to lower altitudes the total number of ions transported antisunward was reduced (Knudsen et al., 1981).\nTheoretical calculations by Brace et al. (1995) showed that the transterminator flow could transport more ions antisunward than were required to maintain the nightside ionosphere and it was suggested that some of these ions might be lost to the solar wind.\nLimited in situ ionospheric observations aboard PVO were made in the pre-dawn sector at low latitudes in 1992 in the declining phase of solar cycle 22 under conditions of moderate solar flux (∼120sfu).\nThe observed ion densities in this sector were significantly larger than those that would be expected in the absence of an antisunward ion flow.\nThis suggested that ion transport was significant in this sector (Brannon et al., 1993).\nThe PVO observations showed that the total transterminator flux was 23% of that at solar maximum and that the largest reductions in the number of ions transported antisunward occurred at the highest altitudes (Spenner et al., 1995).\nThe PVO mission did not include in situ observations of the Venusian ionosphere around solar minimum, however the behaviour of the ionopause was inferred from PVO radio occultation profiles, for which the temporal data coverage was less extensive than for the in situ measurements.\nThe ionopause was at significantly lower altitudes at solar minimum than at solar maximum, typically between 200km and 300km for all SZA (Kliore and Luhmann, 1991).\nThe radio occultation profiles from PVO also showed that the transport process was severely inhibited (Knudsen et al., 1987).\nRadio occultation profiles from Venera 9 and 10 observed the ionopause at higher altitudes in the terminator region at solar minimum with altitudes between 600km and 800km (Gavrik and Samoznaev, 1987).\nThe Venusian ionosphere exhibited a number of asymmetries between the dawn and dusk sectors.\nBrace et al. (1982) observed that the ionopause was higher on the dawn side than at dusk due to interaction with the solar wind.\nMiller and Knudsen (1987) reported larger antisunward velocities within the ionosphere on the dawn side than on the dusk side above an altitude of 400km, with the pattern reversed below this altitude.\nThe dawn-dusk asymmetry below 400km was largely attributed to photoionisation as plasma in the post-noon sector had been exposed to sunlight for longer than plasma in the pre-noon sector.\nThe plasma flow from the dayside to the nightside was driven by the day-to-night pressure gradient, with the higher plasma densities in the post-noon sector enhancing the nightward transport of ions on the dusk side.\nThe super-rotation of the neutral atmosphere also enhanced the ion flow on the dusk side and reduced the flow on the dawn side due to collisional interactions between the ions and the neutral species.\nA subsequent modelling study at the altitude of the peak density in the ionosphere (∼140km) showed that differences in the thermospheric composition between the dawn and dusk sides may also cause asymmetries in the ionosphere at these altitudes due to changes in the dominant chemical reactions (Fox and Kasprzak, 2007).\nBetween August 2008 and October 2009 Venus Express (VEX) was in an orbit with periapsis near 86°N and an altitude between 185km and 215km with about 10min spent in the ionosphere during each orbit.\nTaken collectively over many orbits the in situ ionospheric measurements cover all local time sectors, with each orbit sampling the terminator region at polar latitudes.\nIn the current study these observations are used to determine the plasma distribution near the terminator and to show that the transport process contributes to the maintenance of the nightside ionosphere close to solar minimum.\nInstrumentation\nVenus EXpress (VEX) is the first European mission to Venus (Titov et al., 2006).\nThe VEX spacecraft was inserted into a near polar orbit in April 2006 and so every orbit sampled the terminator region at polar latitudes.\nThe Analyser of Space Plasmas and Energetic Atoms (ASPERA-4) package on VEX contains an ELectron Spectrometer (ELS), an Ion Mass Analyzer (IMA), a Neutral Particle Detector (NPD) and a Neutral Particle Imager (NPI) (Barabash et al., 2007).\nIn August 2008 periapsis was lowered from an altitude of around 300km to 185km, allowing the spacecraft to sample deeper into the ionosphere.\nObservations made using the IMA sensor once this manoeuvre had occurred are of particular interest to the present study.\nThis instrument observes the ion energy per charge, E/q, the mass per charge, m/q, and the arrival direction of each ion as well as the number of ions observed.\nIt has a 360° instantaneous field of view in azimuth and ±45° field of view in elevation in the spacecraft frame of reference and an energy range of 10eV-30keV.\nThe standard observing mode used during the period considered in this study was a scan in decreasing energy through 96 equal logarithmic steps, observing for 250ms at each.\nThese measurements were made at all azimuths simultaneously at a given elevation.\nThe elevation angle was varied through eight positions, which gave a total cycle time of 192s.\nObservations\nData subsequent to the lowering of the periapsis of VEX were considered for the study.\nOne Venus year of data were selected between 4th August 2008 and 17th March 2009 allowing the spacecraft to sample all local time sectors twice as it transited these sectors at high latitudes in opposite directions half a Venusian year apart.\nPeriapsis was at 86°N during this interval.\nThe ion counts as a function of energy observed by the IMA during a spacecraft transit between 04:30 UT and 06:30 UT on 9th August 2008 are shown on a logarithmic scale in the upper panel of Fig. 1.\nThe ion counts as a function of mass channel number are shown in the lower panel of Fig. 1 with lower channel numbers corresponding to higher mass ions (Barabash et al., 2007).\nThese data from 9th August 2008 are considered as an example to show how data from the entire year were selected and processed.\nThe data in the lower panel show two clear ion populations; one with a higher ion mass per unit charge (lower mass channel number) observed between 05:28 UT and 05:47 UT and one with a lower ion mass per unit charge (higher mass channel number) observed before and after this time interval.\nPrior to 04:46 UT and after 06:03 UT the IMA observed ions with energies of some 300-800eV (Fig. 1, upper panel) with a low mass to charge ratio (high channel number in Fig. 1, lower panel) indicating that the spacecraft was in the solar wind.\nIn the intervals from 04:46 UT to 05:28 UT and 05:47 UT to 06:03 UT the IMA sensor observed ions over a larger range of energies than observed in the solar wind, from some 200eV to 1keV with mass to charge ratios similar to that observed in the solar wind.\nThese data suggested that the spacecraft was in the shocked solar wind, downstream of the bow shock.\nThe observations closest to periapsis, between 05:28 UT and 05:47 UT, showed ions at energies below some 50eV with higher masses than those observed in the solar wind.\nThese low energy ions were interpreted as being of planetary origin.\nInspection of the datasets from a large number of orbits showed that it was convenient to locate the Ion Composition Boundary (ICB), which marks the transition between the shocked solar wind and the planetary plasma (e.g. Martinecz et al., 2008), by considering the mass channel number at which the largest number of ions was observed in each 192s cycle.\nData from times at which the mass channel number of the maximum ion count was 15 or less were taken to correspond to altitudes below the ICB.\nThese data were then considered for further analysis.\nFor example, in the data set for 9th August 2008 shown in Fig. 1, the data between 05:28 UT and 05:47 UT were interpreted as being from inside the ICB.\nThese data are shown within the pink box in Fig. 1, and it was these data that were considered for further analysis in this particular example.\nThe spacecraft velocity at periapsis (∼200km) was ∼10kms-1, which was larger than the ion velocities of ∼3kms-1 observed by PVO at these altitudes (Knudsen and Miller, 1992).\nTo ensure that the ions were detected, observations were only considered if the spacecraft ram direction was within the field-of-view of the IMA.\nThis selection criterion meant that observations were only considered when the spacecraft attitude was suitable for observing the ions.\nThe IMA observed in the ram direction for all, or part, of the time when VEX was within the ionosphere on 136 orbits, and data from this sub-set of orbits (136 orbits out of 226 orbits) was considered for further analysis.\nIn this subset of 136 orbits, ions were observed at eight elevation angles during each cycle of 192s duration.\nFor each cycle of each orbit the ion count at the elevation angle with the maximum ion count was found and considered further.\nUsing the counts from this elevation the next step was to obtain the \"summed ion count\" for the cycle, defined as the total ion count summed over all energy levels below 100eV.\nThus a value of the summed ion count was determined for each cycle.\nThe duration of each complete cycle was 192s, however, the summed ion count corresponded to observations from only one of the eight elevations and only a proportion of the 96 energy levels, with the actual observations at one elevation angle and at energies below 100eV being conducted in 6.5s.\nDuring this time interval the spacecraft moved some 65km (6.5s times the satellite velocity of ∼10kms-1).\nThus the summed ion count was observed over a horizontal distance of some 65km which is approximately 0.01 Rv where Rv is the radius of Venus (6052km).\nThe summed ion counts for all cycles are plotted in Venus Solar Orbital (VSO) coordinates in Fig. 2.\nThe positive x-axis is directed towards the Sun.\nThe positive y-axis is orthogonally directed and opposite to the planetary orbital velocity i.e. towards dawn, which is opposite to the Earth due to the retrograde rotation of Venus.\nThe largest summed ion counts were in the polar region close to periapsis where the spacecraft sampled the lowest altitudes.\nIn this region the spacecraft was in the topside ionosphere, where the ion density decreases with increasing altitude.\nData in Fig. 2 exhibit asymmetries in both the dawn-dusk and noon-midnight directions.\nTo investigate the dawn-dusk asymmetry data were selected from a narrow region aligned with the dawn-dusk axis.\nThis region was centred on the terminator and had a width of 0.4 Rv (the x coordinate was restricted to |x|<0.2 Rv).\nThe observations in this region were then binned into intervals of 0.1 Rv in the dawn-dusk direction (y-direction) near the y=0 axis.\nThe small number of points further from this axis required larger bins and an interval of 0.2 Rv was considered between |y|=0.3 Rv and 0.5 Rv and an interval of 0.25 Rv between |y|=0.5 Rv and 0.75 Rv.\nThe median and quartile values of the ion counts in each bin are plotted in the upper panel of Fig. 3.\nA strong dawn-dusk asymmetry was observed, with the median counts larger on the dusk side than on the dawn side by almost an order of magnitude with median values of ∼6×105 on the dusk side and ∼5×104 around dawn.\nA similar plot for a noon-midnight narrow region is shown in the lower panel of Fig. 3 with a restriction that |y|<0.2 Rv.\nThe observations were binned into intervals of 0.1 Rv between |x|=0.0 Rv and 0.3 Rv, 0.2 Rv between |x|=0.3 Rv and 0.5 Rv, 0.5 Rv between |x|=0.5 Rv and 1.0 Rv, and 1.0 Rv for -0.2 Rv<x<-1.0 Rv.\nThis ensured sufficient numbers of points in each bin.\nA noon-midnight asymmetry is apparent, with larger median summed ion counts ∼3×105 in the noon sector.\nVariability is observed on the dayside where the counts are expected to decrease away from the terminator as the spacecraft moves to higher altitudes and to increase because of a decreasing solar zenith angle.\nThe ion counts decrease rapidly on the midnight side to values of ∼5×104.\nHowever, the upper quartile showed that significant numbers of ions could be present nightward of the terminator (located at x=0) and that these values could be comparable to those on the dayside ionosphere with values as large as ∼8×105 recorded in both the day and night sectors.\nThe summed ion counts considered in the preceding paragraphs were for energies less than 100eV.\nThe energy level within this range at which the largest number of ions occurred during each cycle of 192s was determined.\nFor each cycle, the energy of this level was then corrected for the spacecraft potential using the method of Coates et al. (2008) based on the analysis of the ionospheric photoelectron peaks, and the corrected value considered as the energy representative of the ions at the location of the spacecraft.\nTo investigate ion flow in the terminator region an additional constraint was imposed to restrict observations to within ∼30° latitude of the pole.\nPeriapsis was close to 86°N throughout the study period of one Venus year, and the restriction was done by considering only observations at an altitude of 500km or lower.\nThe resulting data were then divided into four bins depending upon the direction of travel of the spacecraft;•\nSpacecraft travelling essentially from noon-to-midnight (within 45° of this direction);\n•\nSpacecraft travelling essentially from midnight-to-noon (within 45° of this direction);\n•\nSpacecraft travelling essentially from dawn-to-dusk (within 45° of this direction);\n•\nSpacecraft travelling essentially from dusk-to-dawn (within 45° of this direction).\nThe spacecraft velocity at periapsis was essentially constant for all observations, with a mean value of (9.78±0.01)kms-1.\nFor each bin the median value of the observed energy was determined.\nThis was (11±3)eV for the noon-to-midnight bin and (20±4)eV for the midnight-to-noon bin, with the uncertainties set by the upper and lower quartiles.\nThe larger ion energies in the midnight-to-noon bin suggested that these ions had a velocity component that was antiparallel to the spacecraft direction of travel and the smaller values in the noon-to-midnight bin suggested that these ions had a velocity component that was parallel to the spacecraft direction of travel.\nTaken together both of these observations suggest that the ions travelled in the noon-to-midnight direction.\nFor both the dawn-to-dusk and dusk-to-dawn bins the energies were (18±4)eV.\nThe difference in the ion energies of these bins was zero within the error margin, which suggested that there was no net ion flow in this direction.\nDiscussion\nResults have been presented of ion counts and energies measured by the ASPERA-4 experiment onboard the VEX spacecraft as it traversed the Venusian ionosphere at polar latitudes.\nStrict selection criteria were applied to the data to ensure that the measurements used in the study were of ionospheric ions.\nMedian ion energy values near the midnight-noon meridian were larger when the spacecraft traversed from midnight-to-noon than from noon-to-midnight.\nThe larger values of the former case suggested that the ions had a velocity component that was antiparallel to the spacecraft direction of travel, while the smaller values of the noon-to-midnight traversal suggested that the ions had a velocity component parallel to the spacecraft direction of travel.\nThis suggested the nightward transport of the ions at polar latitudes.\nMedian values near the dawn-dusk meridian were identical for traversal from dawn-to-dusk and from dusk-to-dawn within the error margins suggesting that there was no net ion flow in this direction.\nTaken collectively the observed ion energies therefore indicated an ion flow predominantly in the noon-to-midnight direction.\nThe spacecraft velocity near periapsis was essentially the same for all orbits and all directions of travel and so the difference in the ion energy between the midnight-to-noon and noon-to-midnight traversals, (9±7)eV, may be attributed to the flow of ions.\nBy using the same assumption as Knudsen and Miller (1992) that the ions were primarily singly ionised oxygen, and that the measured energy difference was representative kinetic energy of the ions a nightward ion velocity of (2.5±1.5)kms-1 is estimated.\nIt is appreciated that there are substantial uncertainties in this velocity and that the IMA was operating close to the lowest energies it could observe, however it is encouraging that this velocity is in broad agreement with Knudsen and Miller (1992) who reported antisunward ion flows of some ∼3kms-1 at these altitudes.\nA dawn-dusk asymmetry in the plasma distribution of the Venusian ionosphere has been reported by Miller and Knudsen (1987) with larger plasma densities observed in the dusk sector.\nTheir study was conducted at low- and mid-latitudes around solar maximum, and the observation associated with the asymmetry of plasma transport where higher density plasma was drawn antisunward (nightward) from the post-noon sector as a transterminator flow.\nThe dawn-dusk ion asymmetry in the current study (Fig. 3, upper panel) was consistent with their interpretation.\nThe observed ion counts in the noon-midnight plane (Fig. 3, lower panel) suggested that the transterminator flow was highly variable.\nThe median values of the three points immediately sunward of the terminator showed the largest values.\nThe median values fell rapidly nightward of the terminator, as expected in the absence of a plasma source.\nThe lower median value of ∼8×104 on the dayside at 0.4 Rv was a likely consequence of the spacecraft sampling at higher altitudes where the ion densities were expected to be lower.\nIndeed, sunward of 0.5 Rv no data points were recorded.\nThis may be explained by the altitude of the ionopause falling to 200km-300km on the dayside (Kliore and Luhmann, 1991) and the spacecraft sampling above these altitudes when it was located ∼0.3 Rv sunward of the terminator.\nThe upper quartile values varied substantially between adjacent bins.\nUpper quartile values in the nightside at a distance of less than 0.5 Rv from the terminator were similar to, or greater than, the median values on the dayside.\nThis suggested that in a substantial number of cases the ion counts nightward of the terminator were comparable to the values in the dayside ionosphere, although in general the ion counts nightward of the terminator were lower than those observed on the dayside as expected in the absence of a plasma source.\nThis indicated that, at times, a process was operating to maintain the nightside ionosphere although the occurrence of this process was highly variable.\nIn summary the observations of ion energies indicated that a nightward ion flow across the terminator at solar minimum can occur.\nThe ion counts show that such a flow is highly variable but the results indicate that it can contribute to the maintenance of the nightside ionosphere.\nConclusions\nIn situ ion observations made by the ASPREA-4 experiment onboard the Venus Express spacecraft at solar minimum have shown dawn-dusk and noon-midnight asymmetries.\nIon energies observed when the spacecraft trajectory was directed midnight-to-noon were significantly higher than those observed when the trajectory was directed noon-to-midnight.\nThis difference in ion energies suggested an antisunward transterminator flow with a velocity of (2.5±1.5)kms-1.\nIt is suggested that this flow contributes to maintaining the nightside ionosphere near the terminator region at solar minimum.\nThe interpretation of the antisunward flow was reinforced by observed asymmetries in the ion number counts.\nThe dawn-dusk ion asymmetry showed larger numbers of ions on the dusk side than on the dawn side consistent with the previously reported observations of antisunward transterminator flow at solar maximum from PVO.\nFor the noon-midnight asymmetry larger numbers of ions occurred on the dayside and there was substantial variability in the observations of counts on the nightside.\nIn a substantial number of cases the number of ions nightward of the terminator was comparable to the number observed on the dayside.\nIn other cases the number of ions nightward of the terminator was much lower, as expected in the absence of a plasma source.\nThese observations suggested that the transterminator flow was highly variable and, in some cases, did not operate at all.\nAcknowledgements\nThe authors would like to thank the ASPERA-4 team for their extensive work planning, constructing and operating these instruments on the Venus Express spacecraft, and the subsequent dissemination of these data.\nThe assistance of Neville Shane from Mullard Space Science Laboratory, University College London in implementing software tools at Aberystwyth University is gratefully acknowledged.\nFinancial support for this paper was provided by the UK Science and Technology Facilities Council under grant PP/E001157/1.\n\n",
    "shortText": "",
    "termVector": [],
    "language": {
        "lang": "en"
    },
    "entities": [],
    "mentions": [
       "ner",
        "wikipedia"
    ],
    "nbest": false,
    "sentence": false
}

-> all the ASPERA occurences and correctly identified and linked - if I am not wrong, as well as all the plasma,  plasma densities - as for small segment queries, see the online demo (https://entity-fishing.science-miner.com, sorry if it's very slow because overloaded by other demos on the same machine)
I must also add that for such a scientific document, you could directly send the PDF to the service. It really takes advantage of  GROBID structuring to control the right content to be processed and disambiguated by entity-fishing - e.g. avoid linking reference markers within the text. It also manages automatically sliding context window. Results would be much cleaner.


autodiff fails under numpy 1.23

Something in the numpy 1.23 release broke autodiff; in particular, float0 arrays are being converted to bool:
import jax
import numpy
print(numpy.__version__)
print(jax.grad(lambda x: x+0., allow_int=True)(1).dtype)

Newest numpy:
1.23.0
bool

previous version:
1.22.4
[('float0', 'V')]

Temporary pinning to fix CI in https://github.com/google/jax/pull/11220

Located the issue to this line: https://github.com/google/jax/blob/b623ed58b0415f31b4c2f2c389220f1e51de8d93/jax/interpreters/ad.py#L65
In numpy 1.22, dtype(t) is float0 is True, and in numpy 1.23 dtype(t) is float0 is False.

This is the operative change in numpy:
import numpy as np
from jax import dtypes
print(np.__version__)
print(np.result_type(dtypes.float0) is dtypes.float0)

Before:
1.22.4
True

After:
1.23.0
False

I don't know for sure, but I suspect this is the relevant change: https://github.com/numpy/numpy/pull/19345/

OK, I think this is the result of the new ensure_canonical functionality added in https://github.com/numpy/numpy/pull/19226
Part of the reason I think this is because of this little quirk:
In [1]: from jax.dtypes import float0

In [2]: import numpy as np

In [3]: np.result_type(float0) is float0
Out[3]: False

In [4]: np.result_type(float0, float0) is float0
Out[4]: True

Along with the fact that NPY_DT_CALL_ensure_canonical is only called on the result for the single-input case: https://github.com/numpy/numpy/blob/89b942e41b45ddd91762e704d3f2ca5677a320b7/numpy/core/src/multiarray/convert_datatype.c#L1633
I'm not sure exactly the mechanism whereby this generates a copy, but it seems clear that the fix could go one of two ways:

Somehow change our definition of float0 so it is in a canonical form that doesn't generate a copy when NPY_DT_CALL_ensure_canonical is called, or
Stop relying on is identity to determine if a dtype is equal to float0

Option 2 is probably safer in the long run, as I can find no explicit guarantee that functions like np.dtype and np.result_type will return no-copy references for non-built-in dtypes. However, equality checks for numpy dtypes are annoyingly polymorphic, so this must be used with care (probably dtype is float0 should be replaced with np.dtype(dtype) == float0 for safety). Also, since equality check is slightly more expensive than identity check, and since this is used so often throughout the JAX package, this change may have a trace-time performance impact.
I'm going to look deeper and try to find exactly where the copy is being generated, but unless something else comes to light, I think option 2 is our best bet.

I believe the ensure_canonical check for void types leads to this function: https://github.com/numpy/numpy/blob/d4baf3641471971552206b02f94323a54b54d99a/numpy/core/src/multiarray/dtypemeta.c#L295 which ends up generating a copy for JAX's definition of float0. This was changed a few months back in https://github.com/numpy/numpy/pull/19346
Here's the TODO that broke our use-case: https://github.com/numpy/numpy/blame/d4baf3641471971552206b02f94323a54b54d99a/numpy/core/src/multiarray/dtypemeta.c#L324-L325

Additionally, there are at least two regressions in numpy v1.23 that are causing test failures in the JAX test suite: https://github.com/numpy/numpy/issues/21838 and https://github.com/numpy/numpy/issues/21840

If anyone encounters this, the fix was part of JAX v0.3.14.


add debug information for vs in windows platformDevelop

add debug information for vs in windows platform

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.SKY-20230424HUG\Administrator seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Provide way to style bottom toolbar

This is really cool. I was wondering if it is possible to allow the user to style the bottom toolbar? Or would something like that not be possible?
i.e: here

For example, I'm currently using this: https://github.com/initialxy/cordova-plugin-themeablebrowser but would love to use this instead though the missing feature would be providing a way to style the bottom toolbar with my own images and also provide a hook in order to get callbacks to button presses via javascript. Would something like this be possible via the SafariViewController?

To my knowledge, styling the bottom toolbar or adding images is not possible with the Safari View Controller. This is a limitation of the native component. The only styling you can use is changing the tint color of the icons/text, shown here https://github.com/EddyVerbruggen/cordova-plugin-safariviewcontroller/blob/master/demo/index.html#L41

Thanks for the reply @johnthepink
Do you know how someone would go about building something similar to what facebook has built for their inappbrowser:

Currently I'm playing around with  https://github.com/initialxy/cordova-plugin-themeablebrowser  but it seems to be very slow and doesn't let me insert two toolbars to style and doesn't show a url bar only page title :/

@aaronorosen I don't know of any cordova plugins that do what you are talking about out of the box, but there may be. It sounds like you may need to fork something like the themeablebrowser plugin and add the functionality that you want.


Add dark mode feature working

Please assign this issue to me @devtayade so that i can start working on it.


Support Next.js

Thank you for your great library. This is a feature request.
The following error occurs when used with Next.js.
Error: Hydration failed because the initial UI does not match what was rendered on the server.

I can use useEffect or dynamic import to get around this, but I would prefer to use this library in a SSR environment if possible. I look forward to Next.js support.

Just tested the library with a new nextjs typescript app and no issues:

 "dependencies": {     "classnames": "^2.3.2",     "next": "12.3.1",     "react": "18.2.0",     "react-dom": "18.2.0",     "react-headless-pagination": "^0.2.1"   },   "devDependencies": {     "@types/node": "18.7.23",     "@types/react": "18.0.21",     "@types/react-dom": "18.0.6",     "eslint": "8.24.0",     "eslint-config-next": "12.3.1",     "typescript": "4.8.4"   }
Please provide an example repo to demonstrate the issue.


WebUI should show more succeed trials by default

Right now, NNI WebUI only show 5 succeed trials by default. It's not enough for normal scale experiment, so suggest to change the default number from 5 to 50.

Released in v0.3


Failed to scrape socket: Failed to parse File not found.

Hi,
I have download phpfpm_exporter and installed on some of my  web server on AWS EC2 with Bitnami/NGINX package.
Here is my phpfpm_exporter.service

[Unit]
Description = PHP-FPM Prometheus Exporter
[Service]
SyslogIdentifier = phpfpm_exporter
ExecStart =/usr/local/bin/phpfpm_exporter --phpfpm.socket-paths /opt/bitnami/php/var/run/www.sock
[Install]
WantedBy = multi-user.target

For some odd reason, one of the servers works perfectly fine, but then I am encourting this following error with others.

Oct 27 08:02:52 ip-10-129-19-93 systemd[1]: Started PHP-FPM Prometheus Exporter.
Oct 27 08:02:52 ip-10-129-19-93 phpfpm_exporter[18333]: 2022/10/27 08:02:52 Starting phpfpm_exporter (version=0.6.0, branch=HEAD, revision=7177e606317822df06d567a4c14d085c40d54ef6)
Oct 27 08:02:52 ip-10-129-19-93 phpfpm_exporter[18333]: 2022/10/27 08:02:52 Build context (go=go1.16.5, user=root@742eee, date=20210605-16:49:46)
Oct 27 08:02:52 ip-10-129-19-93 phpfpm_exporter[18333]: 2022/10/27 08:02:52 Starting Server: :9253
Oct 27 08:03:05 ip-10-129-19-93 phpfpm_exporter[18333]: 2022/10/27 08:03:05 Failed to scrape socket: Failed to parse File not found.
Oct 27 08:03:35 ip-10-129-19-93 phpfpm_exporter[18333]: 2022/10/27 08:03:35 Failed to scrape socket: Failed to parse File not found.
Oct 27 08:04:05 ip-10-129-19-93 phpfpm_exporter[18333]: 2022/10/27 08:04:05 Failed to scrape socket: Failed to parse File not found.

Am I missing something? Can't figure out what's causing this.

does this exist?
/opt/bitnami/php/var/run/www.sock
Do you have pm.status_path = /status enabled on php fpm config? (its commented by default)

@Lusitaniae
this is what's in the php-fpm.conf
listen=/opt/bitnami/php/var/run/www.sock
I missed pm.status_path= /status , but after I have this enabled. Now I got this.
Oct 27 12:51:01 ip-10-129-19-92 phpfpm_exporter[4517]: 2022/10/27 12:51:01 Failed to scrape socket: dial unix /opt/bitnami/php/var/run/www.sock: connect: no such file or directory
So I guss the www.sock file location isn't what I think it is....

@Lusitaniae
Never mind~ I got it to work!
Thank you! This is a very useful tool! Keep up the great work!

no problem!


"Manage Following" page for easier unfollowing/cleanup

In the /$/following page, how about adding a "Manage" button beside the existing "Discover channels" button.  It'll show you a ClaimList of currently-following channels, so that you'll have the ability to browse through them and "Unfollow" them.
Currently, we'll have to enter the channel's page one by one in order to unfollow.  The alternative is to edit the wallet directly, but there's no nice GUI showing the thumbnail of the channels.

We actually used to have such a page/feature but it was removed during one of the redesigns. Not sure how often you to go mass unfollow, but I think it's good to have a list somewhere outside of the sidebar. Would be nice to unfollow channels that are abandoned there too - since that's broken currently.


Fix NearFutureProps vref

again not quite sure why this broke, but NearFutureProps has its own .version
file and running NetKAN confirms that it is finding the correct one

LGTM. Merging with thanks!


View File in Explorer

Hello,
Somehow in the article cannot find if using new EDGE the option "View File in Explorer" is being audited for file operation?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 3494b782-92ad-e365-3398-bd2d760d10c6
Version Independent ID: fa4bca98-3975-23dd-dfac-f23049c71d01
Content: Search the audit log in the Microsoft Purview compliance portal - Microsoft Purview
Content Source: microsoft-365/compliance/search-the-audit-log-in-security-and-compliance.md
Service: o365-seccomp
GitHub Login: @markjjo
Microsoft Alias: markjjo

@markjjo Please help us in resolving this issue. thanks

@yogkumgit @markjjo
Thanks for the action! I have verified with MS Support, and they confirm no audit applies when View File in Explorer is used. So I would recommend updating the doc.

@markjjo Please reply. Thanks

@lightupdifire Thanks for your feedback! New issues and pull requests for this content are closed while we update this content to support upcoming feature improvements.


Update PostCSS packages

Update<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>Changes:

indent is no longer needed accordingly to changelog
options from Object to Array syntax
postcss is now a peer dependency

ref: https://github.com/webpack-contrib/postcss-loader/blob/master/CHANGELOG.md#400-2020-09-07
Part of making way for Webpack 5 #9994
Reference to initial pr #10003 reverted in #10216

@ianschmitz & @ai I've created a new pr for updating postcss to v8
I do see multiple versions of postcss but I don't think it will be solved until all plugins are updated to the new plugin format (without a postcss dependency?)
<EMAIL_ADDRESS>
resolve-url-loader

<EMAIL_ADDRESS>
postcss-preset-env
postcss-normalize Compatibility with PostCSS 8
css-loader
optimize-css-assets-webpack-plugin

<EMAIL_ADDRESS>
react-scripts

<EMAIL_ADDRESS>
postcss-safe-parser

regarding postcss-browser-comments I could not find any open issues regarding updating to postcss8
In our private build setup we also had to add autoprefixer as a dependency - but for now the CRA build haven't complained about it.

@ianschmitz & @ai I've created a new pr for updating postcss to v8
I do see multiple versions of postcss but I don't think it will be solved until all plugins are updated to the new plugin format (without a postcss dependency?)
<EMAIL_ADDRESS>
resolve-url-loader

<EMAIL_ADDRESS>
postcss-preset-env
postcss-normalize Compatibility with PostCSS 8
css-loader
optimize-css-assets-webpack-plugin

<EMAIL_ADDRESS>
react-scripts

<EMAIL_ADDRESS>
postcss-safe-parser

regarding postcss-browser-comments I could not find any open issues regarding updating to postcss8
In our private build setup we also had to add autoprefixer as a dependency - but for now the CRA build haven't complained about it.

LGTM

I do see multiple versions of postcss but I don't think it will be solved until all plugins are updated to the new plugin format (without a postcss dependency?)

Yeap, for the transition period we will still see PostCSS in deep dependencies.

LGTM

I do see multiple versions of postcss but I don't think it will be solved until all plugins are updated to the new plugin format (without a postcss dependency?)

Yeap, for the transition period we will still see PostCSS in deep dependencies.

Any updates on this?

Many thanks @raix. Sorry about the long delays

No worries @ianschmitz :)

When we should expect this to be released?

@raix does postcss-normalize 9 actually support postcss 8?

@radiosilence Thanks it's been unclear as postcss should work with older plugins - we should bump normalize to 10.0.0

Yep, postcss-normalize 10.0.0 has been released so we should indeed bump it


Configure Application Load Balancer for SDAP

Status:

Load balancer deployed in unity-venue-dev on the private subnets but not fully tested
ARN: arn:aws:elasticloadbalancing:us-west-2:429178552491:loadbalancer/net/k8s-sdap-sdapingr-48c5609acc/97a16ec49446bfd4
DNS Name: k8s-sdap-sdapingr-48c5609acc-97a16ec49446bfd4.elb.us-west-2.amazonaws.com
Listener port for SDAP endpoints: 8080
Next step: Configure API Gateway and VPC Link to provide a public path to this load balancer in order to test it.

@jjacob7734 ping for status.

Load balancer deployed with healthy target group (SDAP driver node) and functional listener on port 8080 for SDAP endpoints.


Feat/new acs

Use latest orbit-db-store

Depends on: https://github.com/orbitdb/orbit-db-eventstore/pull/22


closes postman act2 issues 474 & 475

Closes Issues #474 #475
Changes proposed in this pull request:

reordered cards - swapped 6 and 7
added definitions in cards
minor fixes in grammar, etc.

@kavuong

going to merge your branch into an overall Postman branch


Fix race condition in freerdp_channels_client_load that could cause memory leak

If g_pInterface is set to NULL outside the critical section in one thread while another thread is in the critical section, the channel client context allocated in the VirtualChannelEntry won't end up getting freed.
The channel client context is normally loaded from g_pInterface in FreeRDP_VirtualChannelInit and stored in the pChannelInitData, then copied from there onto the pChannelOpenData structure in FreeRDP_VirtualChannelOpen and finally freed in freerdp_channels_free.

@freerdp-bot test.

@clivest Nice catch, but will have to look at this in more detail. What I specially find confusing is why is the context for each channel stored in the same variable? Should that not be a list with contexts for each channel loaded?

Sure. Took me a while to figure out what was going on.

why is the context for each channel stored in the same variable?

You mean the g_pInterface variable? The context for each channel is only stored in this variable temporarily. It's set in the channel's VirtualChannelEntry (called through the pChannelClientData->entry function pointer) via assignment to *EntryPoints.ppInterface. The channel context is then read from g_pInterface in FreeRDP_VirtualChannelInit, which is always called back in the scope of the  VirtualChannelEntry call, and stored on the channelInitData.
The g_channels_lock should be held around modifications to the g_pInterface and g_ChannelInitData global variables. As I see it, the bug here is that g_pInterface is modified outside the critical section.
I think it's quite an odd design choice, however. I think it looks like the client.c code has been forced to fit the VirtualChannel interface, rather than designing the interface to fit the code (an alternative implementation, for example, could add an extra argument to FreeRDP_VirtualChannelInit to pass the channel context). I'm guessing this is to model the Windows RDP channel interface.

@clivest the client was more or less forced on the interface that's true but this was required in order to have the same  (or at least something that can simply be re-used or converted) Channel API as on windows. But you right it looks odd in that case ;)

@clivest generally +1 for your PR. The only thing I was wondering where you have observed multiple threads at this point? - If I'm not mistaken these parts are executed from the main thread when the command line is parsed

these parts are executed from the main thread when the command line is parsed

@bmiklautz Indeed. It looks like all of the current FreeRDP clients call freerdp_channels_client_load() from the main thread. I'm playing around with an application that instantiates multiple clients in the same process and ran into this problem when clients start simultaneously.
I think it looks like this area of the code base is intended to be thread-safe - there's a lock that's held around most modifications to the shared state - and could be made so with a straightforward change.
When creating the pull request, I didn't realise that all current clients only run this from the main thread. This pull request, while I think still valid, is less severe/pressing than I initially thought.

@akallabeth any objections?


Group exposed ports in ps output

Fixes #10302
Signed-off-by: Colm Hally<EMAIL_ADDRESS>

Thanks, @ColmHally
An example output was posted here: https://github.com/docker/docker/issues/10302#issuecomment-71396684
Should the output in https://docs.docker.com/reference/commandline/cli/#ps be updated to include a range (for illustration)? A short note below the example describing that port-ranges are shown "grouped" would be nice there as well.

Thanks, @thaJeztah
Good catch re: docs - I'll add a short example now to the docs.

I think there's no real need to add a "separate" output, but it can be put in the output that's already there.

@thaJeztah, I've added a short note to the docs and rebased my commits. Any further thoughts?
Also, I didn't realise that it was also possible to publish a range of ports to the host.. Do you think we need to add support for those ranges in the ps output?

If possible, yes. I think the original issue also was about publishing a large range of ports (e.g 1000-2000)

Docs LGTM - @fredlf @jamtur01

Build failed.

Docs LGTM after my copy edit. Thanks for the contribution.

Thanks @fredlf - will incorporate your edits and add support for published ports later this evening.

I've added support for grouping published ranges of ports and @fredlf, I've made the changes you pointed out as well.
Grouping will work for ports published like so:
$ docker run -p 1000-2000:1000-2000 ubuntu:14.40 bash
eefa3dbcdd1cba22540dcf6787d7d2c56d654dc95b693de7027d4f35ed889cc0
$ docker ps
eefa3dbcdd1c        ubuntu:14.04        "bash"              11 seconds ago      Up 5 seconds        <IP_ADDRESS>:1000-2000->1000-2000/tcp   modest_galileo

where there is an exact match between the host and internal container port range. However, ports published without an exact match (such as -p 1500-2500:1000-2000 or -p :1500-2500) are simply printed out individually (as before):
$ docker run -p 1500-2500:1000-2000 ubuntu:14.40 bash
5cebbad0bf0cf5a1ab482fd22b889b04f61851045ceabfd9a70d46dec0527365
$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS    NAMES
5cebbad0bf0c        ubuntu:14.04        "bash"              2 minutes ago       Up About a minute   <IP_ADDRESS>:1500->1000/tcp, <IP_ADDRESS>:1501->1001/tcp, <IP_ADDRESS>:1502->1002/tcp, <IP_ADDRESS>:1503->1003/tcp, <IP_ADDRESS>:1504->1004/tcp, <IP_ADDRESS>:1505->1005/tcp, <IP_ADDRESS>:1506->1006/tcp, <IP_ADDRESS>:1507->1007/tcp, <IP_ADDRESS>:1508->1008/tcp, <IP_ADDRESS>:1509->1009/tcp, <IP_ADDRESS>:1510->1010/tcp, <IP_ADDRESS>:1511->1011/tcp, <IP_ADDRESS>:1512->1012/tcp, <IP_ADDRESS>:1513->1013/tcp, <IP_ADDRESS>:1514->1014/tcp, <IP_ADDRESS>:1515->1015/tcp, <IP_ADDRESS>:1516->1016/tcp, <IP_ADDRESS>:1517->1017/tcp, <IP_ADDRESS>:1518->1018/tcp ...............

Another more comprehensive example:
$ docker run -dt -p 443:443 --expose=400-405/udp -p 4327-4655:4327-4655 -p <IP_ADDRESS>:6000-6003:6000-6003 -p <IP_ADDRESS>:32000-32005:32000-32005/udp ubuntu:14.04 bash
519be5a7927fb7ac40ca7550216c623f3737d5f216d58e36be7ff61d4718b92e
$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED              STATUS              PORTS                                                                                NAMES
519be5a7927f        ubuntu:14.04        "bash"              About a minute ago   Up 10 seconds       <IP_ADDRESS>:443->443/tcp, 400-405/udp, <IP_ADDRESS>:4327-4655->4327-4655/tcp, <IP_ADDRESS>:6000-6003->6000-6003/tcp, <IP_ADDRESS>:32000-32005->32000-32005/udp   serene_torvalds

@ColmHally I noticed that you have unrelated commit from @jfrazelle in your PR. Could you remove it pls?

@ColmHally Also, could you pls write test in integration-cli. Should be pretty simple.

hey @ColmHally looks like this needs a rebase, feel free to ping me right after and I will review, sorry for the delay on this, we really appreciate this patch :)

hey @ColmHally I ended up rebasing for you and adding a test in #10835 so you don't need to worry about back and forth with fixes now. Thanks so much for the patch.

Thanks @jfrazelle and @LK4D4! Have been meaning to get to this, but just didn't get a chance.


bv.get_section_by_name broken in most recent dev build

This call was working before updating to the most recent dev build. I get the following error:
>>> bv.get_section_by_name('.text')
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "C:\Program Files\Vector35\BinaryNinja\plugins\..\python\binaryninja\binaryview.py", line 3698, in get_section_by_name
    result = Section(section)
  File "C:\Program Files\Vector35\BinaryNinja\plugins\..\python\binaryninja\binaryview.py", line 552, in __init__
    self.handle = core.handle_of_type(handle, core.BNSection)
  File "C:\Program Files\Vector35\BinaryNinja\plugins\..\python\binaryninja\_binaryninjacore.py", line 12733, in handle_of_type
    raise ValueError('expected pointer to %s' % str(handle_type))
ValueError: expected pointer to <class 'binaryninja._binaryninjacore.BNSection'>

From pdb it looks like "value" is an instance of "handle_type" instead of a pointer to it:
(Pdb) isinstance(value, ctypes.POINTER(handle_type))
False
(Pdb) isinstance(value, handle_type)
True

I see that this is already being addressed, please ignore

Its fine I'll reopen it until the issue is actually fixed. Making this fix actually exposed a refcount issue that I haven't yet sorted out.

This was fixed in v1.1.1357


Move up instance IP note

The note about instances under the cover with internal IP could be moved before the traffic flow explanation in order to better understanding of the flow and not lead to confusion about an IP value that doesn't appear in the diagram

#assign-reviewer: @erjosito

Hey @dmelgarejoPDESGO that is a good feedback, thanks for the PR!

@ckittel @erjosito - Could you review the commit I added to fix punctuation in the article?


Hyperline cannot render when installed

I get the following error:

I took a quick look inside package.json and saw it is indeed not listed as a dependency. I guess that will fix it.

please merge above PR 😢


Investigate clang-format action for ideas on customisable docker base image

See https://github.com/jidicula/clang-format-action
Top-level action is a composite action and somehow controls the base image used for the docker image. This allows them to support lots of clang-format versions. Potentially could do something similar here to also allow running in parent image, without needing to do the faff with installing packages inside our action's container. Or it might not work at all.

Hi, there is another important use-case for this: the way clang-tidy-review currently works, it always runs on ubuntu 23.04, which sometimes has incompatible library versions w.r.t. the system where the compile_commands.json was generated.
In my case, the system where I run the build is (read: must be) Ubuntu 22.04, which ships Python 3.10, so clang-tidy inside the 23.04 docker image (which ships Python 3.11) can't find the Python.h header at the location indicated by the compile_commands.json.

I'd really really like to implement this, I just don't have time to investigate properly at the moment! If there's anyone reading this who's interested, please feel free to give it a crack!


Messages under "Invoice" and "Send" are not displayed correctly and cannot be edited

longer message entered under Invoice is not visible and cannot be edited.

A message without spaces (e.g. a series of numbers) is not completely visible in the upper message area. For better illustration I have entered text without spaces.

@garm01 I'm unable to reproduce. Which one OS and wallet version?
Video: https://share.getcloudapp.com/o0uEER4P

To test it, in the first example, I also used the Enter key when entering text. The text is then moved without this being visible in the message field.
With the arrow keys you can scroll up and down. But this is not so optimal. The same effect is sometimes seen with Copy & Past of a text.
I am sorry, I should have described this better.

Under "Transfers" , a longer message disappear without the message being made visible with the existing scroll bar.
You can only see it here because the fees are rising.

@garm01 could you check? Not sure if it's fixed.

At "http://desktop-build.symboldev.com", there is no change yet.
You have the possibility to enter 98 characters.
From 99 characters on, an empty field with a scroll bar appears.
By moving the scroll bar, the message can no longer be made visible.
So there is no possibility to edit the message at the beginning without deleting the whole rest (backspace key) before (e.g. for error correction).
If you press enter after the 98 characters, the message is no longer visible and neither is the scroll bar.
The only possibility are the up and down keys. If a user unintentionally pressed enter while entering text (under "Send"), the text disappeared. Under "Sign transaction(s)" the message appears, but this will surely lead to many errors.
Under "Invoice" you can see the message, but the behavior of the message field is the same as under "Send".
Furthermore, the line break under "Invoice" doesn't seem to work properly either. If you enter additional characters after 98 characters, they are simply placed in the middle of the message.

correction:
"Furthermore, the line break under "Invoice" doesn't seem to work properly either. If you enter additional characters after 98 characters, they are simply placed in the middle of the message."
This happens only if you click in the message box after 99 characters.


Dead

I think this project is dead. What about continuing it on our own?

You are free to fork away. Nowadays I'd take a completely different
path to this anyway :)
No dia 04/02/2012, às 20:13, Paul Vorbach
<EMAIL_ADDRESS>escreveu:

I think this project is dead. What about continuing it on our own?

Reply to this email directly or view it on GitHub:
https://github.com/pgte/alfred/issues/18

Yes, from the little I saw, I think it should be rewritten. But something like that takes time...
I still think we need a in-process db.

Yes we do, but I'd do it using a leveldb binding and build from there.
On Feb 4, 2012, at 8:41 PM, "Sérgio Ramos"
<EMAIL_ADDRESS>wrote:

Yes, from the little I saw, I think it should be rewritten. But something like that takes time...
I still think we need a in-process db.

Reply to this email directly or view it on GitHub:
https://github.com/pgte/alfred/issues/18#issuecomment-3813157

Have there been any problems, that you couldn't solve with plain JavaScript objects or what are the reasons why you recommend a binding? Wouldn't it be cleaner to build it entirely in JavaScript without any dependencies. Otherwise you could also use redis/mongodb/couchdb/…

Redis/mongodb/couchdb are all services that are out of process.
Leveldb is an embeddable db engine that is battle-hardened. If anyone
is to take a proj like this seriously and not treat it like another
experiment on node, it has to be based on something ppl trust. Ppl
take their data seriously...
No dia 05/02/2012, às 00:12, Paul Vorbach
<EMAIL_ADDRESS>escreveu:

Have there been any problems, that you couldn't solve with plain JavaScript objects or what are the reasons why you recommend a binding? Wouldn't it be cleaner to build it entirely in JavaScript without any dependencies. Otherwise you could also use redis/mongodb/couchdb/…

Reply to this email directly or view it on GitHub:
https://github.com/pgte/alfred/issues/18#issuecomment-3814478

That's not an easy decision. I don't think that I am the right person for this, because I'm not that experienced in C++.
Maybe I'll do some experiments with a plain JS implementation on my own.

Everyone should do that type of experiment, really learned a lot bout node.
Anyway there already is a good binding for leveldb somewhere I remember reading.
No dia 05/02/2012, às 12:02, Paul Vorbach
<EMAIL_ADDRESS>escreveu:

That's not an easy decision. I don't think that I am the right person for this, because I'm not that experienced in C++.
Maybe I'll do some experiments with a plain JS implementation on my own.

Reply to this email directly or view it on GitHub:
https://github.com/pgte/alfred/issues/18#issuecomment-3817170

Maybe creationix/node-leveldb?

That one is actually not finished, there's  a fork of that one, I'll
check when back to pc.
No dia 05/02/2012, às 13:27, Paul Vorbach
<EMAIL_ADDRESS>escreveu:

Maybe creationix/node-leveldb?

Reply to this email directly or view it on GitHub:
https://github.com/pgte/alfred/issues/18#issuecomment-3817596

This one: https://github.com/my8bird/node-leveldb

This might be a good place to start: https://github.com/PaulKinlan/todomvc/commit/39205e06c4553ceb0c455fbf7d1c69a801c281bb


Added translation Thai language

@bee-san, I will update the Thai language to improve the documents:

README.md
CONTRIBUTING.md
CODE_OF_CONDUCT.md

Thank you. :+1:

you're welcome. 😄


Color Palette

A ColorPalette struct that acts as a hashmap to a predefined set of color.
A Default ColorPatlette will be assigned as Monokai Pro color palette.

colors look more cohesive now
https://github.com/nixon-voxell/bevy_motiongfx/assets/43715558/44b3d707-8394-4a45-b6c2-4a33311815d0


wrong path to version_map

Hi, possibly stupid question here but I can't figure out if something's wrong or if I've installed something incorrectly. I've installed asdf version 2.7.2 through Conda, and when I try to write an asdf file this error occurs:
Traceback (most recent call last):
  File "//miniconda3/envs/envpy3/lib/python3.7/site-packages/asdf/versioning.py", line 53, in get_version_map
    with generic_io.get_file(version_map_path, 'r') as fd:
  File "//miniconda3/envs/envpy3/lib/python3.7/site-packages/asdf/generic_io.py", line 1193, in get_file
    fd = open(realpath, realmode)
FileNotFoundError: [Errno 2] No such file or directory: '/envs/envpy3/lib/python3.7/site-packages/asdf/schemas/stsci.edu/asdf/version_map-1.5.0.yaml'

That version map exists but it's located in /miniconda3/envs/..., is there a way to change the default search path?
Thanks!

Hmm... I haven't seen that before.  What OS are you using?  The leading // in the traceback file path seems odd but that may be unrelated.

I'm on MacOS Mojave. Could be I just need to update something, but I wouldn't know what. My astropy is up-to-date (version 4.2), and I'm using python 3.7.10.

I think generally for MacOS these days, you should not be installing Miniconda into the root dir but instead install it into your user home $HOME dir.  I.e.
All the recent Anaconda or Miniconda installers install into home dir now.
This has to do with Apple reducing permissions to write files to root dir by applications.  Installing code into subdirs of $HOME is much safer and is generally allowed by MacOS.

A solution is to move your old installation to a different directory name and reinstall Miniconda and allow it to update your .bash_profile or appropriate dotfile for whichever shell you use.  When you then create a new env, it should put it into $HOME/miniconda3/envs/.

Thanks, reinstalling Miniconda did the trick.


Chrome died immediately after restart... stopping Prerender

I have been trying to setup prerender locally by taking clone of the github repo but getting the following error while starting the prerender server
Operating System - Windows 11
Chrome Version - Version 111.0.5563.147 (Official Build) (64-bit)
Server.Js
#!/usr/bin/env node
var prerender = require('./lib');
var server = prerender({
chromeLocation: 'C:\Program Files\Google\Chrome\Application\chrome.exe',
chromeFlags: ['--no-sandbox', '--headless', '--disable-gpu', '--remote-debugging-port=9222', '--hide-scrollbars', '--disable-dev-shm-usage'],
});
server.use(prerender.sendPrerenderHeader());
server.use(prerender.browserForceRestart());
// server.use(prerender.blockResources());
server.use(prerender.addMetaTags());
server.use(prerender.removeScriptTags());
server.use(prerender.httpHeaders());
server.start();
ERROR LOGS
2023-04-03T15:37:29.578Z Starting Prerender
2023-04-03T15:37:29.581Z Starting Chrome
2023-04-03T15:37:29.619Z Prerender server accepting requests on port 3000
2023-04-03T15:37:29.639Z Chrome connection closed... restarting Chrome
2023-04-03T15:37:29.639Z Chrome died immediately after restart... stopping Prerender

Can anyone please help me for this ?

I had the same issue. Adding chromeLocation and chromeFlags didn't help.
I reverted the last changes in master from this PR https://github.com/prerender/prerender/pull/748/files and it worked for me.
ihors ~/github/prerender (master) > PORT=1337 node server.js
2023-04-11T11:09:06.270Z Starting Prerender
2023-04-11T11:09:06.272Z Starting Chrome
2023-04-11T11:09:06.275Z Prerender server accepting requests on port 1337
2023-04-11T11:09:06.784Z Started Chrome: HeadlessChrome/112.0.5615.49


Input File Example

Can you attach .abs file example for frc_demo please?

I have attached an abs file and its aligned ppm, like frgc's format. They are in the samples folder.


Sorted structs as per fieldalignment and added lint for further checking.

Sorted structs as per the fieldalginment following the command fieldalignment -fix github.com/startreedata/pinot-client-go/pinot

Added lint for further restricting the unsorted structs.
Fixed couple of minor lint issues.
added a couple of more linters for static analysis of code. some are disabled right now and in following PR, going to fix it.

@xiangfu0, please review. Added linting step based on golangci-lint in the project. Currently, a couple of linters are failing and I will work  on it to fix the code for the failures. Thanks

Let me know if you want to merge this then fix linter, or I will wait for your fix then merge this.

I will make the linter fix changes in another PR. Please merge this one. Thanks.


Update-AzVM step in PowerShell example prompts for RG name

The PowerShell example on this page is incomplete. The last step 'Update-AzVM -VM $VM' prompts for resource group name. Please update the example to include the RG name.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 1ea4398a-8b98-eb03-7e2a-c7e11117a602
Version Independent ID: 1ea4398a-8b98-eb03-7e2a-c7e11117a602
Content: Virtual machine stuck in failed state - Virtual Machines
Content Source: support/azure/virtual-machines/vm-stuck-in-failed-state.md
Service: virtual-machines
GitHub Login: @mimckitt
Microsoft Alias: mimckitt

#assign: @mimckitt


CB-9057: Updated cordova.js for Windows to refer to base.js instead of winjs.js

Fixed this change for cordova-js as well as in cordova-windows.

@stevengill - What is the correct way to make a corodova.js change now?

The correct way is to change it in cordova-windows now.  You can still update legacy-exec cordovajs version but it won't be used when building cordova.js anymore and will eventually be removed.

Thanks, Steve! I think createmobilespec might need an update for this to work. In general, what's the recommended workflow for us to generate cordova.js for a particular platform? Would you use npm link after your recent set of changes?

If you make changes to the platform specific js and want to test it out, I would npm link it to the one in cordova.js/node_modules/platform to test. When we do platform/tools releases, we should make sure the dependency in cordova.js gets updated.