Loop unrolling?

easter3000.apl, after compiling to Futhark with tail2futhark, contains a loop with a known number of iterations: 3.  Unrolling this loop would not just avoid the loop itself, but also permit an intermediate array to be simplified away entirely.  It is of course possible that the C compiler can do this optimisation, but I wouldn't bet on it.
When is it permissible to unroll loops?  Should we bother at all?  Perhaps a conservative loop unrolling rule could give us some benefits, whilst still being cautious enough never to cause problems.

I should note that the loop in question also has a trivial body - it just sums up an array.  The simplicity of the body could also be used as a yardstick - no unrolling of loops with nested loops, for example.

When is it permissible to unroll loops?
whenever you know the size statically -- tradeoffs between
code expansion and getting rid of some instructions.
But if entire arrays dissapear it might be worth it.
(However you need to concentrate on fission -- I have distracted you
enough with my bugs :-) )

Come to think of it one application would definitely be
getting rid of size-1 loops (and replacing arrays of statically
known size 1 with scalars.)
B.t.w. I did some work on fixing the current stream.
Now OptionPricing validates again (albeit the big dataset
reaches 27% memory -- but that may be because I do
not fuse inside a user-defined stream yet -- will continue
tomorrow with streams.
However, we need to fix the unnecessary input/result copying
for SOAC -- it looks like it is possible for the common case
but requires symbol tables and a pass similar to copy-propagation
(just the math gets a bit complicated.) -- we'll discuss more when I see
you.
Best,
Cosmin
On 06/11/2015 06:39 PM, Troels Henriksen wrote:

easter3000.apl
https://github.com/henrikurms/tail2futhark/blob/master/tests/benchmarks/easter3000.apl,
after compiling to Futhark with |tail2futhark|, contains a loop with a
known number of iterations: 3. Unrolling this loop would not just
avoid the loop itself, but also permit an intermediate array to be
simplified away entirely. It is of course possible that the C compiler
can do this optimisation, but I wouldn't bet on it.
When is it permissible to unroll loops? Should we bother at all?
Perhaps a conservative loop unrolling rule could give us some
benefits, whilst still being cautious enough never to cause problems.
—
Reply to this email directly or view it on GitHub
https://github.com/HIPERFIT/futhark/issues/69.


DateTime should have a const "epoch" constructor

There are a few use-cases where having a const DateTime constructor can be useful, such as default parameter's values.
I understand why the current implementation doesn't have const constructors (there is a need for some runtime checks), however having an epoch constructor would allow to use a constant "zero-value" for a DateTime object which would directly create the object without going through the dynamic checks.

Hi Sir, Can you please assign me this task. I will love to work on it :-)

The class itself needs to be constant for that to be possible. It looks like that in the source, but the individual platforms patch that class with more fields which aren't even final (for caching the individual getter values the first time you ask for them, like the VM does).
The epoch value itself could be a different class, with all getters hardwirded to return 0, 1 or 1970 as appropriate.
That risks polymorphism, which may reduce the performance of other code. Not impossible, but less convenient.
Or there could be another class for constant uses, which doesn't cache and is therefore less efficient on repeated calls. (Computing the year usually also implies computing the month and day, which is why caching them all on the first call makes sense.)
It's just not a very good class to make constant, there are too many computations either at creation or when inspecting.

If the year/month/day were calculated on inspection, when passing constant values, wouldn't those basically be set at compilation?
I'm not sure of the level of optimization of the Dart compiler but if it has a math literal with all values already set it should be able to resolve it at compilation. I might be missing some pieces tho :)

Computing the Y/M/D/h/m/s/S values at constant creation time is probably technically possible for UTC dates. It's definitely not possible for local time, since we don't know the local time where the code will run. It's also a complicated computation, that is hard to fit into constant constructors using only potentially constant expressions and no complicated control flow. It's also hard to introduce bounds checks in constant computations.
It still needs a new class to hold those, since the current implementation class has a mutable field, and therefore cannot be constant.
All in all, not going to be easy or generally applicable, and probably not really worth the effort.

You can use my const_date_time package to achieve this.
import 'package:const_date_time/const_date_time.dart';

class MyClass {
  const MyClass({
    this.date = const ConstDateTime(0),
  });

  final DateTime date;
}

for caching the individual getter values the first time you ask for them

@lrhn would using Expando be useful here ?

Using Expando is possible, but not without cost. It's just not as efficient.
Another reason to be against having an epoch constant is that it's just not a very good default value.
There is nothing special about the epoch as a point time. It's an arbitrary date chosen as a base number for the implementation, but using that as a default value in an API is very likely a mistake. You will want a default value that is either clearly recognizable as not a real value (the epoch is still the birthday of real people, using 1st of January year zero would be a better "no value" value for that use case).
So, for a default value, you really should make the parameter nullable and accept null. Using a perfectly reasonable value as default risks either testing that value indirectly if it's a real argument, or assuming the default value means something.
In short, the epoch is not special as a date, it's an artifact of an implementation choice. There is no situation where you should care what the epoch date is, unless you want to use the underlying integer representation.
Not going to do an epoch constant.
Making the class constant in general is maybe possible, but not for local time, and the API, and the currently required compressions in the constructors, really isn't geared to being constant. Like RegExp, it does too much validation in the constructor to be a good constant type.


Let's upgrade to dnx!

Builds currently fail , but work on my machine. People are welcome to look at them whilst I sleep, otherwise I'll look at them tomorrow :)

The travis builds are currently failing with an exception when publishing with the --no-source flag, do we remove this flag?
  at System.IO.BinaryReader.ReadChar () [0x00000] in <filename unknown>:0
  at Microsoft.CodeAnalysis.CvtResFile.ReadStringOrID (System.IO.BinaryReader fhIn) [0x00000] in <filename unknown>:0
  at Microsoft.CodeAnalysis.CvtResFile.ReadResFile (System.IO.Stream stream) [0x00000] in <filename unknown>:0
  at Microsoft.CodeAnalysis.Compilation.MakeWin32ResourceList (System.IO.Stream win32Resources, Microsoft.CodeAnalysis.DiagnosticBag diagnostics) [0x00000] in <filename unknown>:0 ```

@Yantrio nah, downgrade to mono 3.12.x on travis. We'll need to figure this out.... somehow

but then all the tests fail :(

we seem to be blocked by https://github.com/aspnet/Home/issues/498

With this PR, Kestrel is started when using --stdio

See https://github.com/OmniSharp/omnisharp-atom/issues/341

Fixes the stdio not working bug :)


Add hint function in DataFrame.

Adding hint function in DataFrame, which is adding a various types of hint, similar to ks.broadcast() but not only broadcast hint.

Codecov Report

Merging #1415 into master will decrease coverage by 2.29%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #1415      +/-   ##
==========================================
- Coverage   95.04%   92.74%   -2.30%
==========================================
  Files          34       34
  Lines        7964     7970       +6
==========================================
- Hits         7569     7392     -177
- Misses        395      578     +183

Impacted Files
Coverage Δ

databricks/koalas/missing/frame.py
100.00% <ø> (ø)

databricks/koalas/namespace.py
85.00% <ø> (-1.58%)
:arrow_down:

databricks/koalas/series.py
96.92% <ø> (-0.05%)
:arrow_down:

databricks/koalas/frame.py
93.39% <100.00%> (-3.23%)
:arrow_down:

databricks/koalas/generic.py
96.62% <100.00%> (-0.13%)
:arrow_down:

databricks/koalas/usage_logging/__init__.py
24.32% <0.00%> (-70.28%)
:arrow_down:

databricks/koalas/usage_logging/usage_logger.py
50.00% <0.00%> (-50.00%)
:arrow_down:

databricks/koalas/__init__.py
73.07% <0.00%> (-19.24%)
:arrow_down:

databricks/conftest.py
88.67% <0.00%> (-7.55%)
:arrow_down:

... and 4 more

Continue to review full report at Codecov.

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


Docs build issue

For some reason, rsasl is failing to compile on nightly, we need to figure out how to get around that so our users can see the autogenerated docs

Here's a link to the logs from the failed build: https://docs.rs/crate/samsa/0.1.7/builds/1307418
It looks like there are some compilation issues related to lifetimes for example:
[INFO] [stderr] error[E0621]: explicit lifetime required in the type of `provider`
[INFO] [stderr]    --> /opt/rustwide/cargo-home/registry/src/index.crates.io-6f17d22bba15001f/rsasl-2.0.1/src/context.rs:120:14
[INFO] [stderr]     |
[INFO] [stderr] 119 | pub fn build_context<'a>(provider: &'a dyn Provider) -> &'a Context<'a> {
[INFO] [stderr]     |                                    ---------------- help: add explicit lifetime `'a` to the type of `provider`: `&'a (dyn Provider<'a> + 'a)`
[INFO] [stderr] 120 |     unsafe { &*(provider as *const dyn Provider as *const Context) }
[INFO] [stderr]     |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ lifetime `'a` required


Thoughts?

I'm gonna spend some time on this.
Just building upon the actual documentation with things that are ignored to help newer devs.
Any tips on directions or anything?
I'm looking at http://daux.io/Features to generate the site.

I want to include things such as the hidden helpers (object, array, data_get etc). live templates for phpstorm and generally the things that get posted into frontporch daily.

I'd like to take a stab at a more broken-down and detailed version of the official docs, maybe with a focus on common pitfalls and best practices/considerations for each. daux.io looks interesting, would it just be hosted on github?

GH Pages provides more than enough for what we want to do with this :stuck_out_tongue:

I'd like to take a stab at a more broken-down and detailed version of the official docs, maybe with a focus on common pitfalls and best practices/considerations for each.

Hell, sometimes a proper example would just be enough!

Perhaps we could take the existing docs and work from there?
On 23 Feb 2016 12:48, "Harry Torry"<EMAIL_ADDRESS>wrote:

I'd like to take a stab at a more broken-down and detailed version of the
official docs, maybe with a focus on common pitfalls and best
practices/considerations for each.
Hell, sometimes a proper example would just be enough!
—
Reply to this email directly or view it on GitHub
https://github.com/larachat-frontporch/laravel-5-unofficial-docs/issues/1#issuecomment-187686138
.

That sounds like a big task in terms of keeping it up to date. Are we then wanting to support 5.1, 5.2 and 5.3 at the same time?

IMO it'd be better to start fresh, and being an addition to the official docs, rather than trying to replace them. Targeting only the newest version might be the better option here (and perhaps the LTS ones?). It would encourage people to use the latest version of laravel and at the same time force us to rediscover new things and not fall behind.

Great idea, I agree with @thomasruiz on this one. Target the most recent version(s) first, move on to the LTS ones later.
I don't think we should take the existing docs and go from there, that'd only add overhead (reading docs, seeing what's wrong with them, correcting them). We can definitely take "inspiration" from them though :smile:

Taking the existing docs isn't the goal. Dont we want to create a place to find common problems and solutions?
I would say we do it like @thomasruiz said. Also add a section for common used code snippets from larachat.

Let's get the ball rolling!
To be clear, my take of the docs isn't a rewrite of the docs, it's more like a deconstruction of how the components act and behave with each other, a "behind the scenes" look if you will, intended to help people who want a deeper understanding of how things work instead of a cookbook. It'd probably need a fresh structure, because going from the old one would make it all too easy to repeat the old mistakes...

So how do we plan to structure this documentation? And what exactly do we want to put in it? It would be great to have a list of subjects that we must have, then some that we should have, and others that we could have. That'd make the decision process better.

To get back to this... I'd love to see some of the more obscure changes that aren't in the current documentation, like the getRouteKey() method on your models, or a $with property to always eager load.
Should the docs be written in markdown and hosted here on GitHub or should we put it on its own website and see what to do from there?

lets do it first of with markdown, and if it gets big, we can still switch to a website


Add repo name for performance-hub

New PR https://github.com/ministryofjustice/modernisation-platform/pull/5027 was created following a rebase that went a little wrong.


enhance support reading hive table with OpenCSVSerde

Proposed changes
OpenCSVSerde Properties:

Property
Description
Default Value
Supported in Doris

separatorChar
Defines the character used to separate fields (columns) in a CSV file.
,
Yes

quoteChar
Defines the character used to quote fields that contain special characters, like the separator.
"
Yes

escapeChar
Specifies the escape character used for escaping special characters, including quotes and delimiters.
"
Yes

Explanation:

separatorChar: This property defines the character that separates columns in the CSV file. Typically, a comma (,) is used as the default separator.
quoteChar: This character is used to enclose fields that contain special characters (like the separator). For example, if a field contains a comma, it is enclosed in quotes (").
escapeChar: Specifies the character used to escape special characters, such as quotes or the separator. In many cases, a backslash (\\) is used as the escape character.

run buildall

run buildall


Leverage: Implement DirectLiquidationFee

Add to proto (leverage Param)
Improve MsgLiquidate to detect RewardDenom as a uToken (full incentive) or base token (reduced incentive)
Implement reduced incentive in MsgLiquidate when receiving base assets

This is done


Update FloatingPointTypes.swift.gyb

IMO the original message can be confusing because the Float80 type seems to be available only on MacOS.
You can reproduce this error by compiling source code that it and targets an iOS device.

@swift-ci please smoke

@swift-ci please smoke test and merge

@stephentyrone hey Stephen, what do you think if error message would be more concrete about platform? e.g. Float80 is available only on MacOS.

@stephentyrone hey Stephen, what do you think if error message would be more concrete about platform? e.g. Float80 is available only on MacOS.

That would be a lie, since it's also available on Linux / x86_64, right? I don't think trying to precisely define where it's available is especially useful in this error message; what matters is that it isn't available for the current platform, whatever that is.

I.e. I like the solution in this PR.

In case it's not obvious, the Linux build failure is unrelated to this change. I'll re-run the test once it's sorted out.

@swift-ci please smoke test linux


Create Sphinx-based Documentation

The current documentation consists of the README.rst file and nothing else.
The next version should have a nice Sphinx-based documentation with a well formatted API/Source Code Documentation.

Documentation is now produced by sphinx.


Page.RSSLink is deprecated and will be removed in Hugo 0.93.0

Seems like something we'd have to look into:
ERROR 2022/01/16 18:03:10 Page.RSSLink is deprecated and will be removed in Hugo 0.93.0. Use the Output Format's link, e.g. something like:
    {{ with .OutputFormats.Get "RSS" }}{{ .RelPermalink }}{{ end }}
ERROR 2022/01/16 18:03:10 Page.URL is deprecated and will be removed in Hugo 0.93.0. Use .Permalink or .RelPermalink. If what you want is the front matter URL value, use .Params.url

I did not have time to look into the code yet, but quick search gave me this link that seems relevant so far:
https://discourse.gohugo.io/t/page-hugo-is-deprecated-page-rsslink-is-deprecated/27037/2
https://gohugo.io/templates/rss/#the-embedded-rssxml

@svetlemodry I can't find any page.RSSLink or Page.URL in the theme. I also don't get this error when building hugo with v0.92.0, which is the latest release right now.

Heh, yep you are right.
Looks like couple of my projects were using an old version of this template.
Sorry for the noise here! I guess this can be closed then.
Enjoy your weekend!


BugFix at HttpServerHandler, prohibited patterns

According to rfc 3986 section 3.3, path can contain a colon. except
first segment.
check this link.
https://tools.ietf.org/html/rfc3986#section-3.3

add validation for first path of segment
remove unnecessary grouping of regexp
remove unnecessary pattern

'?' : already removed at Strip the query string step

Build fail at checkstyle step.
I will fix it.


import and export support

see import
see export

:+1:
This will also need context-aware statement parsing mentioned here, since imports and exports can only happen at the top scope.

since imports and exports can only happen at the top scope

I can not see this define in MDN, Can you give me some link about this infomation ?

It's in the spec for Module in ES6. ImportDeclaration and ExportDeclaration can be only done at the top level of a module.

@maciejhirsz Thank you :)


[Map Pack] EXU1 Repack

This is a Single Player campaign for UT99, not Unreal - it requires ExcessiveUT and is best run with OldSkool.  Superceded by the EXU2 campaigns.

URL: https://unrealarchive.org/mappacks/unreal/unknown/E/exu1-repack_cd36a64b.html
Hash: cd36a64bc0b9609c4a9b41ec8452a75893f322ef
Current name: EXU1 Repack

Updated. Also updated some other EXU campaigns to SP.


⚠ Spryr has degraded performance

In dccfedb, Spryr (https://spryr.com) experienced degraded performance:

HTTP code: 200
Response time: 3096 ms

Resolved: Spryr performance has improved in 4af4b46 after 13 minutes.


How to request a URL to a conversation?

Description
In the Slack UI on each message you can open the three-dot-menu --> Copy Link.
You can use this link outside of Slack to take you back to that exact message. It's awesome!
How do you create that link from Bolt?
I have the following details:

channel_id
user_id
command_ts
trigger_id

And some other values which I don't think are applicable.
From what I can tell the link is comprised of the following:
https://`.slack.com/archives/<channel_id>/?thread_ts=<command_ts>&cid=<channel_id>`
Any ideas, where I can get that third value?
I'm running bolt v3.12.1
What type of issue is this? (place an x in one of the [ ])

[ ] bug
[ ] enhancement (feature request)
[X ] question
[ ] documentation related
[ ] example code related
[ ] testing related
[ ] discussion

Requirements (place an x in each of the [ ])

[ x] I've read and understood the Contributing guidelines and have done my best effort to follow them.
[x ] I've read and agree to the Code of Conduct.
[x ] I've searched for any related issues and avoided creating a duplicate issue.

Hi @RoYoMi, you can use https://api.slack.com/methods/chat.getPermalink for it!

OOOOH!  Yep that works a treat, thank you


Support csv as an import input

Since we have the capability to output the scan result to csv format in scancode, the aboutcode-manager should support import csv as an input.

@chinyeungli I think we should not support this. There are too many things that are "damaged" in the data structure when you convert a tree structure to a flat CSV. To me the CSV output in ScanCode is a one way street that cannot get you back anything that could resemble the original richly structured scan data. We could build a utility to roughly convert a CSV to something that would look like a bit a structure JSON. And this could be done here or in ScanCode... but that would be highly lossy and subject to much errors. Can you elaborate on what would be your use case?

@chinyeungli: A few things: The CSV output in aboutcode-manager AFAIK is currently only supported for Conclusion data.

I agree that export to CSV is a one-way street.

Will close this for now.


RKE1 - Add a field for setting the backoff value

Detailed Description

RKE1 backoff is a new feature that allows users to configure the number of retries before Rancher gives up creating or updating the cluster due to errors.
We would like to have an option on the cluster edit page for this value:
Name: retry backoff or TBD
Type: integer
Defaut Value: 10
Filed in Cluster Config: TBD

Note: more information will be added once they are available
Context

Please check https://github.com/rancher/rancher/issues/37479 for more details.

Due to a shift in priorities, this is no longer in the v2.6.6 release plans, so moving it to Unscheduled for now.

Closing as stale since backend is no longer scheduled.


Staging URL vs. Console URL for alpha 21?

Hi all,
I'm trying to link the Helium Console to my IoT GUI.
However, the uplinks are sometimes uploaded to https://staging-console.helium.wtf and in other days to https://console.helium.com.
Last week, it uploaded to https://console.helium.com and now to https://staging-console.helium.wtf.
Two weeks ago, it uploaded to staging URL.
BTW, the joins will be shown in both URLs!
Are uplinks for alpha 21 supposed to see in staging or console URL?
Is it randomly now or is it being changed by dev team?
Console URL

Staging URL

Thanks a lot.

That looks like you may have the device(s) registered on both staging and production console. Please make sure  to have a device only registered in one console. Once removed from the other, it may take a while for the router and network to know that this has happened.

Ok let me try to remove the devices in Staging URL.
Thanks a lot.

I deactivate the device in one of the URLs.
The remaning URL works correctly.
Thanks a lot.


undefined symbol: SSLeay

trying to run navcoin-qt on arch linux. i get:
./navcoin-qt: symbol lookup error: ./navcoin-qt: undefined symbol: SSLeay
thanks

Is arch linux your distribution or architecture?
alex

On 15 May 2017, at 20:45, ITwrx<EMAIL_ADDRESS>wrote:
trying to run navcoin-qt on arch linux. i get:
./navcoin-qt: symbol lookup error: ./navcoin-qt: undefined symbol: SSLeay
thanks
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/NAVCoin/navcoin-core/issues/68, or mute the thread https://github.com/notifications/unsubscribe-auth/AXqh3lggzc-vigDM2BZApMGByj8cGuJ6ks5r6J08gaJpZM4Nbh9F.

distro

I’d suggest you to try the x86_64 binary.

On 15 May 2017, at 20:47, ITwrx<EMAIL_ADDRESS>wrote:
distro
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/NAVCoin/navcoin-core/issues/68#issuecomment-301568018, or mute the thread https://github.com/notifications/unsubscribe-auth/AXqh3nMBNko5aGjO0b6rdefVDMGtuBcmks5r6J3SgaJpZM4Nbh9F.

i am. navcoin-4.0.3-x86_64-linux-gnu
thanks

Are all the dependencies as documented in https://github.com/NAVCoin/navcoin-core/blob/master/doc/build-unix.md setup?

are these debian package names or something?

so, if i'm understanding this correctly, navcoin won't work on arch (without replacing my berkely databse version with 4.8 which may not be compat with the rest of my system) because navcoin uses a very old berkely database for compat with debian/ubuntu. Is this the situation?

Nav binaries come with the right berkeley-db version.
I'd say the message you are seeing means a) you are using a binary with the wrong architecture or b) there's a problem with openssl in your system.
Sadly I don't have an ArchLinux where I could test it deeper.

i'm using the qt binary that was in the x86_64 tarball with a 64 bit system.
i have openssl 1.1.0.e-1 and openssl-1.0 1.0.2.k-3 installed. the 1.1 version is arch default and the 1.0 version is an older version required as dependency of qt5-base. Maybe there is an incompatability between the wallet and one or both of these openssl packages?

Same problem with same navcoin-qt binary (4.0.3-x86_64) here on Fedora 26 64bit (having OpenSSL 1.1.0f and a "compat-openssl10-1.0.2j" package installed).
Maybe it would help to include the OpenSSL stuff in the binary. The bleeding-edge distros' OpenSSL versions seem to be incompatible with the current NavCoin codebase.

Has this issue been fixed?  I am trying to run the NAV coin wallet on Arch and getting the undefined symbol: SSLeay error.  Have asked on forum, slack, and reddit page and feel as though it gets ignored, never even get a response.

I'm getting the same error on Arch. Looks like openssl issue.
If I try to compile from source I get this on make check:
➜  navcoin-core git:(master) ✗ make check
Making check in src
make[1]: Entering directory '/home/miloops/media/blockchain/navcoin-core/src'
make[2]: Entering directory '/home/miloops/media/blockchain/navcoin-core/src'
make[3]: Entering directory '/home/miloops/media/blockchain/navcoin-core/src/secp256k1'
make[3]: Leaving directory '/home/miloops/media/blockchain/navcoin-core/src/secp256k1'
  CXX      libnavcoin_server_a-blockencodings.o
In file included from wallet/walletdb.h:12:0,
                 from main.h:24,
                 from blockencodings.cpp:13:
./key.h:238:24: error: invalid use of incomplete type ‘BIGNUM {aka struct bignum_st}’
 class CBigNum : public BIGNUM
                        ^~~~~~
In file included from /usr/include/openssl/bn.h:32:0,
                 from ./key.h:16,
                 from wallet/walletdb.h:12,
                 from main.h:24,
                 from blockencodings.cpp:13:
/usr/include/openssl/ossl_typ.h:80:16: note: forward declaration of ‘BIGNUM {aka struct bignum_st}’
 typedef struct bignum_st BIGNUM;
                ^~~~~~~~~
In file included from wallet/walletdb.h:12:0,
                 from main.h:24,
                 from blockencodings.cpp:13:

@aguycalled I'm having the same issue as @miloops in Arch, either executing QT wallet's binary or trying to compile.
I found this code fix on BitShares for code that seems similar to the one that's throwing the error(s) under NAV's code, it might help get the compatibility between old and newer OpenSSL libs fixed: https://github.com/bitshares/bitshares-fc/commit/fee06a4

@aguycalled I'm having the same issue as @miloops in Arch, either executing QT wallet's binary or trying to compile.
I a code fix on BitShares for code that seems similar to the one that's throwing the error(s) under NAV's code, unfortunately it was reverted because "Max compatible Boost version is not compatible with OpenSSL 1.1.0".
Still, I didn't try it out so it might or might not help getting the compatibility between old and newer OpenSSL libs fixed:
Original fix commit: https://github.com/bitshares/bitshares-fc/commit/fee06a4
Reversal fix commit: https://github.com/bitshares/bitshares-fc/commit/a30647d32e0580217e4bfcb7ccf5493766fcdc0c
OpenSSL 1.1.0 broke some things from 1.0.2 so this might be one of it.
I hope this can help in any way.

@aguycalled @miloops, I was able to recompile everything with OpenSSL 1.0 using the following configure command AND changing the src/qt/navcoingui.h header file to eliminate a couple of repeated declarations, namely, void toggleStacking(); and QAction * toggleStackingAction(); that were throwing the error below.
Configure command used after ./autogen.sh and before the make command:
LDFLAGS=" -L/usr/lib/openssl-1.0 -lssl -L/usr/lib ${LDFLAGS}" CPPFLAGS="-I/usr/include/openssl-1.0 -fPIC -O3 ${CPPFLAGS}"  CXXFLAGS="-I/usr/include/openssl-1.0 -fPIC -O3 ${CXXFLAGS}" PKG_CONFIG_PATH="/usr/lib/openssl-1.0/pkgconfig ${PKG_CONFIG_PATH}" CFLAGS="-fPIC -O3${CFLAGS}" ./configure --with-incompatible-bdb --prefix=/usr --sysconfdir=/etc --libdir=/usr/lib
Declarations error in navcoingui.h header file:

In file included from qt/navcoin.cpp:9:0: qt/navcoingui.h:148:14: error: redeclaration of ‘QAction* NavCoinGUI::toggleStakingAction’      QAction *toggleStakingAction;               ^~~~~~~~~~~~~~~~~~~ qt/navcoingui.h:128:14: note: previous declaration ‘QAction* NavCoinGUI::toggleStakingAction’      QAction *toggleStakingAction;               ^~~~~~~~~~~~~~~~~~~ In file included from qt/navcoin.cpp:9:0: qt/navcoingui.h:248:10: error: ‘void NavCoinGUI::toggleStaking()’ cannot be overloaded      void toggleStaking();           ^~~~~~~~~~~~~ qt/navcoingui.h:236:10: error: with ‘void NavCoinGUI::toggleStaking()’      void toggleStaking();

Seems to have worked, navcoin-qt successfuly generated, I've opened the wallet and I've inputed the base NAVTech server and it's syncing
Regarding the OpenSSL 1.1.0 version compatibility, I found an issue under bitcoin that has several references to other issues that were referenced in order to solve this compatibility:

https://github.com/bitcoin/bitcoin/issues/7086

I hope it's useful.

I'll keep investigating on this, right now we use openssl 1.0.1 when building the binaries

possible fix: https://github.com/peercoin/peercoin/commit/5b09830e5de0f5105534e69dbf4acffb3255869b

Solved, pending pr


add black gloves to clothesmate

About the PR

Adds 4 black gloves to the clothes mate
Why / Balance

Curbs metagaming of thieving and combat gloves by making their visually identical base item more publicly accessible
Changelog
:cl: Whisper

add: Added black gloves to the clothesmate

two PR's that add items to the clothesmate back to back so they make eachother conflict files, pro


Applied fixes from StyleCI

This pull request applies code style fixes from an analysis carried out by StyleCI.

For more information, click here.

close #24


Remove "passthrough" TLS termination mode

"Passthrough" was originally implemented on the bases that there is no
easy way to

provide a cert that works with OpenShift Routers in reencrypt modes
use self-signed certificates with long expiry dates

Hence this commit removes it from the chart, instead making the whole
component MUCH simpler.
Checklist

[x] PR contains a single logical change (to build a better changelog).
[x] Update the documentation.
[x] Categorize the PR by setting a good title and adding one of the labels:
bug, enhancement, documentation, change, breaking, dependency
as they show up in the changelog.
[x] Link this PR to related issues or PRs.

@megian IIRC you have this feature activated in one of the cluster. Is this something you can live with?

@megian IIRC you have this feature activated in one of the cluster. Is this something you can live with?

Since I had to implement something for the re-encrypt cert (It's a EKS cluster) and don't have the time for. I will try to override it or do a fork of the component for this customer.

@megian My idea was that I migrate the existing passthrough setup (it's a single one) after v6 of this component is released, since it was my understanding that there is no requirement to HAVE a passthrough setup at all
I agree @ccremer that a fork should be avoided at all cost :)

@mhutter The original idea was to have a end to end encryption to mitigate any man in the middle attacks. Keycloak would be the first I would try to attack. Reencrypt is less secure, as it does open up the potential the ingress controller has some flaws. From a security view - in my opinion -, the highest possible security configuration should be the default of a security component. This is the reason, why I'm not so convinced to prune this option out of the component.
However configuring a manual certificate for the internal cert is a broken concept from my point of view. As it's insecure to have in example a 10 year certificate (especially for a security component like Keycloak) and we currently also don't have any monitoring implemented, for those certificates.
OpenShift might use https://docs.openshift.com/container-platform/4.9/security/certificate_types_descriptions/service-ca-certificates.html, but my knowledge this is not available on native K8s. https://cert-manager.io/docs/configuration/selfsigned/ might do it.
 Cryptic and painful to manage. Will check, if there is a better option.

Then I misunderstood the reasons why passthrough was used in the first place, sorry for that.
However since we cannot use certmanager for Passthrough because of keycloak, we can agree that "passthrough" only supports Vault as a certificate source, is that correct?


OLS-581

Description

Type of change

[ ] Refactor
[ ] New feature
[ ] Bug fix
[ ] CVE fix
[ ] Optimization
[ ] Documentation Update
[ ] Configuration Update
[ ] Bump-up dependent library

Related Tickets & Documents

Related Issue #
Closes #

Checklist before requesting a review

[ ] I have performed a self-review of my code.
[ ] PR has passed all pre-merge test jobs.
[ ] If it is a core feature, I have added thorough tests.

Testing

Please provide detailed steps to perform tests related to this code change.
How were the fix/results from this change verified? Please provide relevant screenshots or results.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 95.27%. Comparing base (c9af85b) to head (2782ba8).
Report is 14 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #997      +/-   ##
==========================================
+ Coverage   95.21%   95.27%   +0.06%
==========================================
  Files          54       54
  Lines        2174     2181       +7
==========================================
+ Hits         2070     2078       +8
+ Misses        104      103       -1

see 5 files with indirect coverage changes


IsarError: IllegalArg: Please provide a valid directory..

Steps to Reproduce
Hi, thanks for this library. Currently I got an error with this library when I run the project on android emulator API 23 or below.
Here is the error :
I/flutter ( 4185): ╔════════════════════════════════════════════════════╗
I/flutter ( 4185): ║                ISAR CONNECT STARTED                ║
I/flutter ( 4185): ╟────────────────────────────────────────────────────╢
I/flutter ( 4185): ║        Open the link to connect to the Isar        ║
I/flutter ( 4185): ║       Inspector while this build is running.       ║
I/flutter ( 4185): ╟────────────────────────────────────────────────────╢
I/flutter ( 4185): ║ https://inspect.isar.dev/3.0.5/#/49896/KcmGNpQ7LbI ║
I/flutter ( 4185): ╚════════════════════════════════════════════════════╝
I/flutter ( 4185): ----------------FIREBASE CRASHLYTICS----------------
I/flutter ( 4185): IsarError: IllegalArg: Please provide a valid directory..
I/flutter ( 4185):
I/flutter ( 4185): ----------------------------------------------------
E/Surface ( 4185): getSlotFromBufferLocked: unknown buffer: 0x7f1c69dacce0

I'm using Riverpod to provide Isar instance like this :
app_database.dart
final provideAppDb = Provider.autoDispose<Isar>((ref) {
  throw UnimplementedError();
});

mixin AppDatabase {
  static Isar? _isar;

  static Future<Isar> getInstance() async {
    if (Isar.instanceNames.isEmpty || _isar == null) {
      _isar = await Isar.open(
        [
          TokenCollectionSchema,
          UserCollectionSchema,
        ],
        name: "amazing-app",
        inspector: true,
      );
    }

    return _isar!;
  }
}

app.dart
Future<void> main() async {
  await dotenv.load();
  runApp(await intializeApp());
}

Future intializeApp() async {
  WidgetsFlutterBinding.ensureInitialized();

  ConstData.secretKey = dotenv.env["SECRET_KEY"] ?? "";
  ConstData.baseUrl = dotenv.env["BASE_URL"] ?? "";

  await Firebase.initializeApp();

  FlutterError.onError = (errorDetails) {
    FirebaseCrashlytics.instance.recordFlutterError(errorDetails);
  };
  PlatformDispatcher.instance.onError = (error, stack) {
    FirebaseCrashlytics.instance.recordError(error, stack);
    return true;
  };

  final appDb = await AppDatabase.getInstance();

  return ProviderScope(
    overrides: [
      provideAppDb.overrideWithValue(appDb),
    ],
    child: const AmazingApp(),
  );
}

Here is my flutter doctor :
Doctor summary (to see all details, run flutter doctor -v):
[√] Flutter (Channel stable, 3.7.1, on Microsoft Windows [Version 10.0.22621.1265], locale id-ID)
[√] Windows Version (Installed version of Windows is version 10 or higher)
[√] Android toolchain - develop for Android devices (Android SDK version 31.0.0)
[√] Android Studio (version 2021.2)
[√] IntelliJ IDEA Community Edition (version 2020.2)
[√] VS Code (version 1.75.1)
[√] Connected device (1 available)
[√] HTTP Host Availability

• No issues found!

Details

Platform: Emulator Pixel 4 API 23, Emulator Pixel 4 API 22, Emulator Nexus S API 23,
Flutter version: 3.7.1
Isar version: 3.0.5

[x] I searched for similar issues already
[x] I filled the details section with the exact device model and version
[ ] I am able to provide a reproducible example

I have same issue with a new project

Same error message is reported in my Crashlytics.
Mine is only on Android 6 as my app's minimum supported api is 23.
Here is my flutter doctor :
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 3.3.6, on macOS 13.2.1 22D68 darwin-arm, locale en-DE)
[✓] Android toolchain - develop for Android devices (Android SDK version 33.0.1)
[✓] Xcode - develop for iOS and macOS (Xcode 14.2)
[✓] Chrome - develop for the web
[✓] Android Studio (version 2022.1)
[✓] VS Code (version 1.76.0)
[✓] Connected device (4 available)
[✓] HTTP Host Availability

• No issues found!

Isar version: 3.0.5
Stack trace from Crashlytics on Android 6.0.1 device:

Non-fatal Exception: io.flutter.plugins.firebase.crashlytics.FlutterError: IsarError: IllegalArg: Please provide a valid directory... Error thrown Uncaught error: .
       at FirebaseCrashlytics.recordError(firebase_crashlytics.dart:119)

I have the same error
Fatal Exception: io.flutter.plugins.firebase.crashlytics.FlutterError: IsarError: IllegalArg: Please provide a valid directory... Error thrown null.
       at FirebaseCrashlytics.recordError(firebase_crashlytics.dart:119)
       at _initFirebase.<fn>(main.dart:122)

@RakaAlrian  @Dev-Zombie  @dayron9110  @BradKwon  @ritksm
Hi  I'm not expert on it but i solved this problem using this approach.
Installing package path_provider and then  adding a path to may isar opened instance
Future<Isar> isar = Isar.open([GenreSchema], directory: (await getApplicationDocumentsDirectory()).path);
I think that your can have better solutions now but until @simc  update you can use this start point.
Nb: 'I dint use on production  env, i'm still in dev now'

@inkomomutane awesome, this is working! but can you explain more why you prefer using getApplicationDocumentsDirectory? Since the path_provider documentation said :

Consider using another path, such as [getApplicationSupportDirectory] or [getExternalStorageDirectory], if the data is not user-generated.

anyway, thankyou!

Unfortunately some Android devices don't allow automatic directory detection so with v3.1.0 you'll always have to provide a directory yourself (using getApplicationDocumentsDirectory())
Hope this clears up the confusion 🙂


create temporary travis file for melodic testing based on lunar

This is temporary until build.ros.org provides pr testing for melodic.

looks like travis did the right thing on the last run, @wjwwood feel free to merge this whenever


Fix for parallel test error in ADV test run.

Critical Changes
Changes

Updating test methods to fix errors when they are run in parallel.

Issues Closed
New Metadata
Deleted Metadata
Testing Notes

Make sure tests methods in AFFL_ContactAccChange_TEST pass when run all at once.
Once packaged, make sure the ADV ci_feature build can be run without HEDA Test errors. If "UNABLE_TO_LOCK_ROW" shows up in errors, this still isn't resolved.

@jstvz This is a good example of the need for being able to specify a product, ADV in this case, depending on the beta version of another product. This will unblock a PR in ADV (#44), but not until a prod release is cut, in the current setting. Just FYI.

@lparrott I just realized why the build is taking so long. The branch name doesn't start with /feature, so the build system is not picking it up! It needs to be renamed.


code: 1, codeName: CANCELLED

In an RTC live broadcast scenario, there's an error when the microphone callback is used for Google ASR recognition.
When streamingRecognize starts for a while, got this  error:
I/flutter ( 7773): gRPC Error (code: 1, codeName: CANCELLED, message: The operation was cancelled., details: [], rawResponse: null, trailers: {}) GrpcError
flutter  3.16.0
google_speech: ^4.4.0

@

@NSLogZfRee I have just released version 5.0.0 with endless streaming support. Please test if this solves your problem.


Back card not loading issue

When you swipe the card lightly and  the card is not dragged, then when you swipe again it doesn't load next card and shows a white screen instead, then it loads when the swiping is fully completed. This happens then for all the remaining cards on the stack.

Doesn't work in --release and --profile as well.

#5 Fixed here


profiles (cookies, auth, cache, history) for webview

hi,
I'm actually building a web testing tool using this library.
I wonder if there's a way to separate multiple "profiles" for the inapp webview.
Each profile will be self contained - entire cookies, httpauth, history, cache, etc, basically everything. Chrome does have a profile folder, so is it possible to achieve something like that using this library ?

No, this is not possible, otherwise, it would be already implemented/added.
Unfortunately, there are no such native official APIs to make it possible.
Only for iOS, you may try to set the incognito:  true WebView option, that uses the WKWebsiteDataStore.nonPersistent() native iOS class.
But, because of this, unfortunately, you will lose WebView data (such as cookies, cache, etc) after app restart, because non-persistent WKWebsiteDataStore can't be saved to disk.
Note that this is not a limitation of this plugin or any other WebView plugin but on the native WebViews of the various Operating Systems. It is simply not possible until the native Platform adds such features.

Also, people may get confused thinking that a WebView is a Browser (such as Chrome, Firefox, Safari, etc.). It is not.
WebView: https://www.pcmag.com/encyclopedia/term/webview
Web Browser: https://www.pcmag.com/encyclopedia/term/web-browser

Thank you for replying.
I'm aware of what a webview is (I'm an android developer in the past). But
I was not sure if a webview allowed you to hook into the cookie, history,
etc this way.
I saw
https://www.theverge.com/2021/3/2/22309154/google-chrome-reading-list-new-profile-bookmarks-colors-features
, so I wondered if that was possible. Thanks for clearing it up.
On Tue, 6 Apr, 2021, 21:53 Lorenzo Pichilli, @.***>
wrote:

Also, people may get confused thinking that a WebView is a Browser (such
as Chrome, Firefox, Safari, etc.). It is not.
WebView: https://www.pcmag.com/encyclopedia/term/webview
Web Browser: https://www.pcmag.com/encyclopedia/term/web-browser
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/pichillilorenzo/flutter_inappwebview/issues/788#issuecomment-814254670,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAASYU2I3FYS5KBKHW4QS6TTHMYRNANCNFSM42PBKMIA
.

No problem! Thanks to you! I was just clarifying it because a lot of people think that.
Also, you should consider that the Android Chrome app is not even using the WebView. It uses the same render engine and JavaScript engine, but other things are written in native C code and some Java code with "bridge". So, they have access to the "full power" of the engine.
Hope Android and iOS adds support for such things! It would be very nice to have!

Thanks !
That makes a lot of sense.
I guess I'll have to compile chromium then :(
I was hoping to stay in Flutter ecosystem...but I guess I'll have to go
back to java.
On Tue, 6 Apr, 2021, 22:12 Lorenzo Pichilli, @.***>
wrote:

No problem! Thanks to you! I was just clarifying it because a lot of
people think that.
Also, you should consider that the Android Chrome app is not even using
the WebView. It uses the same render engine and JavaScript engine, but
other things are written in native C code and some Java code with "bridge".
So, they have access to the "full power" of the engine.
Hope Android and iOS adds support for such things! It would be very nice
to have!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/pichillilorenzo/flutter_inappwebview/issues/788#issuecomment-814267617,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAASYU3CWQV4GO3WVGZZ4YDTHM2XNANCNFSM42PBKMIA
.

I tried once but it got a lot complicated and it was taking so much time to compile that I gave up.

However, you can stay in the Flutter ecosystem but then you need to expose the chromium methods that you want to use on Flutter.

Also, this could be valid only for Android.
On iOS, this won't be ever possible. Apple doesn't allow other WebViews than its native WKWebView to render web content.

Another path on this is to use a parallel space app -
https://beebom.com/best-parallel-space-alternatives/
The opensource/commercial version of this engine is this -
https://github.com/asLody/VirtualApp
On Tue, 6 Apr, 2021, 22:36 Lorenzo Pichilli, @.***>
wrote:

However, you can stay in the Flutter ecosystem but then you need to expose
the chromium methods that you want to use on Flutter.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/pichillilorenzo/flutter_inappwebview/issues/788#issuecomment-814283641,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAASYU7435TANZGTBA6U52TTHM5R7ANCNFSM42PBKMIA
.

sorry to msg on this issue, but wanted to find out if we can use a
different webview than supplied by system for your plugin ?
P.S. Android only I know.
For example, can I supply this webview as a jar file to
flutter_inappwebview ?
https://github.com/delight-im/Android-AdvancedWebView
On Tue, Apr 6, 2021 at 10:41 PM Sandeep @.***> wrote:

Another path on this is to use a parallel space app -
https://beebom.com/best-parallel-space-alternatives/
The opensource/commercial version of this engine is this -
https://github.com/asLody/VirtualApp
On Tue, 6 Apr, 2021, 22:36 Lorenzo Pichilli, @.***>
wrote:

However, you can stay in the Flutter ecosystem but then you need to
expose the chromium methods that you want to use on Flutter.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/pichillilorenzo/flutter_inappwebview/issues/788#issuecomment-814283641,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAASYU7435TANZGTBA6U52TTHM5R7ANCNFSM42PBKMIA
.

Nope, it doesn't make any sense because the WebView needs to work with the Flutter with Message Channels.
You need to implement that kind of Flutter - Android (or any other platform) 2-way communication.
In any case, what is the problem? Is there a feature missing?


StatisticalRethinking.jl v3: Just a set of methods (such as plotcoef, precis, etc.)?

In https://github.com/StatisticalRethinkingJulia/TuringModels.jl/pull/23#issuecomment-626664042 I suggested to end up with a StatisticalRethinking.jl to provide just a set of methods (such as plotcoef, precis, plotbounds, link, quap etc which are useful for all 3 ...Models.jl repos) and move the actual use of these methods to the specific mcmc model repositories. In the book these methods are typically explained in the Overthinking sections.
This is a significant change in direction so I wanted to post very early on to get feedback.
Someone who wants to take the StatisticalRethinking course and is interested in Turing would use either TuringModels.jl (for just the models) or a still to be created StatisticalRethinkingTuring.jl. Or these 2 repos could be combined.
Similarly, for Stan it would mean a lot of the current contents of StatisticalRethinking.jl would either move to StanModels.jl (basically all models) and the core course materials would end up in StatisticalRethinkingStan.jl.
Just a thought for now as more and more folks (rightly so!) seem interested in a Turing specific version.

Some initial pros and cons why this might be a good/not so good idea:
Pros:

StatisticalRethinking.jl methods can be reused in all three mcmc model repos (DynamicHMCModels, TuringModels and StanModels. And also in other contexts, e.g. recently I was looking a bit into DiffEqBayes and wished I had plotcoef() easily available. But in its current form, StatisticalRethinking is too big.

From chapter 5 onwards I found I really wanted to hold on to results of several models and ended up adding many model clips, e.g. m5.1.jl etc. This started a line of thought to structure e.g. StanModels.jl in such a way that I can refer to that model with something like include(stan_model_path("..", "models", "05", "01", "s", ".jl")) and with the actual results as m05_01_s in calls such as p = read_samples(m05_01_s, output_format=:particles).

For Turing the "s" would be replaced by a "t", for DynamicHMC with a "d".

Much more debate on how to improve methods such as plotcoef.

Cons:

Model formulations live outside StatisticalRethinking.jl or e.g. StatisticalRethinkingTuring.jl

I'm not quite sure what's yet to come in the book and the full extend of the repo but here are some thoughts, take them with a grain of salt.
There seems to be quite a bit of different content:

Models from (for now) three different frameworks
(generally useful) tools for working with the results
Code for working with the results. Since (I think) both Turing and DHMC return MCMCChains at least for those it might be similar.
Code, independent of the models (the DAG stuff, I couldn't find an elegant way to do the posterior predictive checks in chapter 3 and what else have you)
General tips for doing this kind of stuff in Julia, like DataFrames, plotting, etc. (I guess some specifics but mostly links to existing documentation?). For example a line like y .~ Normal.(mu, s) in Turing makes sense to me but without knowledge of broadcasting via dots it must look either like magic or hieroglyphs.
???

All that should make sense from a perspective of

Reusing neat tools elsewhere
Keeping everything maintainable
Have everything easily installable
Make it possible to go though the repo alongside the book without having to search where the next code block might be hidden
???

So I think:
Generally useful tools could go in an extra package independent of StatisticalRethinking with a more fitting name (since they aren't really bound to the book if much more people might find them useful). This package could be imported in StatisticalRethinking and used from there.
From a working-with-the-book perspective having a single repo might be best. That allows just going through it chapter by chapter, depending which framework you like you use model05_01_s or model05_01_t and can easily compare them since they would be right next to each other.
That would also answer the question where everything goes: in there.
Since that repo is only to be used while working with the book it doesn't really matter if it's heavy.
However, it might make everything more messy and unwieldy. It might come down to how much of the repo is models vs. the rest.
Having a separate TuringModels would make it easier to point someone without connection to the book there for some inspiration, on the other hand I'm not sure how much good these models can do without the context of the book.

Thanks @karajan9
Many good points in your response, I want to think through the consequences of your suggestions a bit more.
But for now, I will not touch TuringModels without letting you know, so if you want, you can add/improve to that repo and if later on (very likely anyway) we want to refactor it, that's ok as well.

On May 12, 2020, at 16:01, karajan9<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
I'm not quite sure what's yet to come in the book and the full extend of the repo but here are some thoughts, take them with a grain of salt.
There seems to be quite a bit of different content:
Models from (for now) three different frameworks
True.
(generally useful) tools for working with the results
Code for working with the results.
Generally useful tools could go in an extra package independent of StatisticalRethinking with a more fitting name (since they aren't really bound to the book if much more people might find them useful). This package could be imported in StatisticalRethinking and used from there.

I have a slight preference to work towards making StatisticalRethinkingJulia mcmc package neutral. I would like to finish chapters 7 and 8 first, but then parallel to your work I could experiment with a new package StatsiticalRethinkingStan.jl while storing the models in StanModels.jl.
Although  tools like plotcoef, link, precis, etc in the end might be of interest outside the SR context, the ideas did come from Richard (McElreath) and by keeping them in a base package named StatisticalRethinking.jl honors this. Maybe until some of them, once mature and proven widely useful, migrate to other packages like StatsPlots.jl?

Code, independent of the models (the DAG stuff, I couldn't find an elegant way to do the posterior predictive checks in chapter 3 and what else have you)

If I can pull off a reasonable version of StructuralCausalModels.jl I was planning to use that for the DAG stuff (to me a key part of the SR book).
I’ll take a look at the posterior predictive checks in chapter 3, I had the impression the current StatisticalRethinking.jl covered that reasonably well.

General tips for doing this kind of stuff in Julia, like DataFrames, plotting, etc. (I guess some specifics but mostly links to existing documentation?). For example a line like y .~ Normal.(mu, s) in Turing makes sense to me but without knowledge of broadcasting via dots it must look either like magic or hieroglyphs.
???
Since (I think) both Turing and DHMC return MCMCChains at least for those it might be similar.
I think MCMCChains is very useful to check chains. Right now I have not found it particularly easy to use for subsequent work. Turing returns MCMCChains.Chains objects. DynamicHMC returns NamedTuples. For Stan.jl it is optional, I mostly use Particles and DataFrames these days.

Recently a lot of good work has been done on MCMCChains.jl. Once this work settles down and the Array and DataFrame conversion functions are still in there, it provides an easy way to switch to e.g. DataFrames and Arrays.

All that should make sense from a perspective of
Reusing neat tools elsewhere
Keeping everything maintainable
Have everything easily installable
Make it possible to go though the repo alongside the book without having to search where the next code block might be hidden
???
So I think:
From a working-with-the-book perspective having a single repo might be best.
That would also answer the question where everything goes: in there.

Agreed.

That allows just going through it chapter by chapter, depending which framework you like you use model05_01_s or model05_01_t and can easily compare them since they would be right next to each other.

Maybe models should be named as identical as in the book, except we can’t use dots. Thus m5_1t in file m5.1t.jl?

Since that repo is only to be used while working with the book it doesn't really matter if it's heavy.

Agreed as long as we don’t run into CI problems again.

However, it might make everything more messy and unwieldy. It might come down to how much of the repo is models vs. the rest.
Having a separate TuringModels would make it easier to point someone without connection to the book there for some inspiration

Time will tell, refactoring is ok and all in the game. But even in that case, storing models in separate files in a single repo would allow that.

, on the other hand I'm not sure how much good these models can do without the context of the book.

True.
One final point, I would really like to keep the StatisticalRethinkingJulia repos a course, particularly with respect to the exercises in the book.
Rob

I have a slight preference to work towards making StatisticalRethinkingJulia mcmc package neutral. I would like to finish chapters 7 and 8 first, but then parallel to your work I could experiment with a new package StatsiticalRethinkingStan.jl while storing the models in StanModels.jl.

I don't really have an opinion on this yet. I think it depends on how much of the material is MCMC neutral or could have a common interface (DataFrames? Particles?) if it makes sense.
For example, I wasn't aware that quap currently depends on Stan. I wrote a short version that takes in a Turing model to get the NLL and returns the MAP via Optim.jl as well as the hessian, akin to what Richard does. (I'm thinking about making a PR when I find a good place for it.)
He also wrote a parser so he can have a math-like DSL instead of relying on Stan. I'm not sure how much motivation I have to do it the same way, considering Turing models already look pretty close (just upside down) and will be needed later on anyway (at least for me).
But that would then mean that the Stan/Turing path splits even earlier.

Although  tools like plotcoef, link, precis, etc in the end might be of interest outside the SR context, the ideas did come from Richard (McElreath) and by keeping them in a base package named StatisticalRethinking.jl honors this. Maybe until some of them, once mature and proven widely useful, migrate to other packages like StatsPlots.jl?

Hm, I can see that point (although I can't really judge how much of anything he came up with since I have no history in the field). If these methods are widely useful I think at least making them easily accessible (without heavy dependencies like Stan or Turing) would be beneficial. Putting them in a package like StatsPlots might increase reach but I don't think that's a must at all.

If I can pull off a reasonable version of StructuralCausalModels.jl I was planning to use that for the DAG stuff (to me a key part of the SR book).

To be honest, I've gotten a little lost with all the packages related to this. Again, I think I have to invest more time just going through everything.

Recently a lot of good work has been done on MCMCChains.jl. Once this work settles down and the Array and DataFrame conversion functions are still in there, it provides an easy way to switch to e.g. DataFrames and Arrays.

I'm not quite sure what all the alternatives might be but for working with data/samples DataFrames is probably both a save and good bet.

Maybe models should be named as identical as in the book, except we can’t use dots. Thus m5_1t in file m5.1t.jl?

Just curious, why can't there be any dots?

Agreed as long as we don’t run into CI problems again.

I really don't have any idea about CI (except the basic concept) sooo... I'm just going to follow your lead here.

One final point, I would really like to keep the StatisticalRethinkingJulia repos a course, particularly with respect to the exercises in the book.

What do you mean by that?

I'm not yet at a point where I see a clear value of the parser work. As you have found as well, to 'translate' to Turing (and in fact to Stan) the sequence is reversed. As I like Turing's PPL I considered a translation from that to Stan (somewhat like it is done in DiffEqBayes.jl) but didn't go there at that point in time. With your work that might change.
I'm also still on the fence about quap(). Early on I show a few ways of computing the MAP, none of which I found completely satisfactory.
Mohammed provided me a MAP version for Turing 2 years ago but at that time Turing simply took too long for even the simple models in SR. Now Turing/AMHC for SR models is mostly on par I would be very interested in your version. Why not include it in TuringModels.jl's src directory?
For Stan I tried Optim.jl, StanOptimize.jl and Stan's logpdf formulation, but decided to just fit a Normal distribution to Stan samples around the max density. If the value of having a proper quap() would become more clear I might have to fix this.
Dots in Julia are for field access, a variable m5.1 will be rejected.
By my final point I mean that the repo should not contain pre-cooked solutions for all exercises. The repo needs to provide tools that help finding solutions without having to understand all ins and outs of e.g. Julia graphic packages, Julia's Distributions.jl, etc.

As I like Turing's PPL I considered a translation from that to Stan (somewhat like it is done in DiffEqBayes.jl)
Since I don't know the internals of DiffEqBayes, can you explain what that would mean?

Dots in Julia are for field access, a variable m5.1 will be rejected.
Oh yes, I thought you were talking about file names here.

By my final point I mean that the repo should not contain pre-cooked solutions for all exercises.
I'm not sure what I think about that yet. I agree that students should be incentivized to actually work through the exercises, on the other hand, here they don't have the opportunity to get their results checked or to discuss and compare with classmates like in a real course. I have done the exercises so far, I'm quite confident in some results, for some I'd like to cross-check my solutions but there isn't really a way to do this except asking on Discourse etc. which isn't really ideal either.
Maybe a separate repository linked here could be a sensible compromise?

DiffEqBayes contains a function stan_string() that maps (by string interpolation) distributions (from Distributions.jl) to the Stan language equivalents. This only deals with priors and likelihoods, most other stuff needed in a Stan program comes from a template.
Let's shelve the exercise discussion for now, do what you would like to do. Once a bit further down the road we might have a better understanding about what is ok.
I still need to come back to your earlier (very useful) remark that you got a bit lost in all the packages!

Let's shelve the exercise discussion for now, do what you would like to do. Once a bit further down the road we might have a better understanding about what is ok.

Sounds like a good idea.

I started working through the book in Turing and collected everything here: https://github.com/karajan9/statisticalrethinking
I try to translate pretty much everything so my goal is to use the resulting code to fill the holes in TuringModels. I'm not quite sure yet how that's going to work best since I started from scratch with no regard for what there already.

Doing that made it clearer to me that splitting up the package or collecting out the generally useful functions in a separate package would probably be a good idea. Currently I would be using StatisticalRethinking just for the precis function (I'm only up to chapter 5 and half of the functions (link or sim) don't work as well with the Turing workflow) and for that I get a ton of dependencies installed, including all things Stan which I'm probably not going to use at all.
I'm not sure yet, but it could also happen that there will be less overlap between the Stan, Turing, ...  versions because the helper functions need to work differently. quap already got a Turing specific version, sim could work well with the newly released posterior prediction functionality of Turing.
Then again, this is only relevant if the package is intended to be used as a dependency and not exclusively as a "stand-alone package".

I still need to come back to your earlier (very useful) remark that you got a bit lost in all the packages!

As far as I can see right now (again, I'm only up to chapter 5 so things might look different for that latter chapters) the map looks like:
StatisticalRethinking: many models in Stan, helper functions and additional translations from the R code with resulting plots
TuringModels: some of the models translated to Turing but not much else
DynamicHMC: similar
StanModels: not sure, is this going to be a TuringModels equivalent for Stan?
StructuralCausalModels: for working with DAGs
I think the main point for me was that for working with Turing I need a non obvious mix of StatisticalRethinking and TuringModels and even then there isn't everything there (just because it hasn't been translated yet but that wasn't clear to me).

Great input @karajan9. Some thoughts:

If you only use precis I would suggest to copy it to TuringModels.
Common functionality could go in a new package, e.g. StatisticalRethinkingCore.jl. That would then become a dependency for other SR packages.
I don't know (yet) if the workflows are sufficient similar to have useful content for this SRCore.jl package. Withquap it's clear that the Turing quap method might be a thin layer, and maybe the same is true for sim, but I don't think there is a reason why e.g. link could not be shared. Time will tell. I definitely don't like the current implementations of sim and 'link`.
I still think it would be nice to have just the models in a separate package to easily allow comparisons between models, use the models from within other packages such as StructuralCausalModels.jl, and maybe make the main package, StatisticalRethinking.jl, at some point mcmc implementation agnostic (based on an ENV setting and/or using Requires.jl?).
Anyway, my main conclusion is that it is very interesting to see where you will end up. It has never been my intention to provide translations for all of the R functionality, just basically to help folks get started with SR in Julia. But all of that might change given your feedback!

For now I'm closing this issue. For now I have decided to not split StatisticalRethinking.jl in a set of common components and move all scripts to a repo like StatisticalRethinkingStan.jl. It is a very breaking change and I'm not sure how substantial that set of common components is.

Hi Rob, sorry for taking so long for getting back to you -- I could have sworn I already responded, but alas, here we are.
I think you are right, a common package might more sense at a later time -- if at all --  when it's more clearly a good idea. If you are now populating StatisticalRethinkingStan, what do you plan to become of StatisticalRethinking?

It has never been my intention to provide translations for all of the R functionality, just basically to help folks get started with SR in Julia. But all of that might change given your feedback!

Well, this started because of necessity: if I want to run the models I need most of the other code as well -- why not do the whole thing then.  I also think this would be good for people who are not familiar with Julia or don't want to dive as deep down. This gives the same chance as with R to just play around with the existing code.

For now I'm planning to keep StatisticalRethinking.jl up to date/operational, even if it is just for consistency for current users.
Once we figure out if we need a place to store common functions that might be a long term direction for it. Right now StatisticalRethinking.jl is a package. I think for users to run/modify the scripts (and Pluto notebooks) a project that can be copied is a better tool (as in your setup).
If it turns out users like projects like StatisticalRethinkingTuring (basically what you are working on), StatisticalRethinkingStan and maybe others and we don't need above common functions repo, we might just might simply phase it out or e.g. use it for comparisons between Julia mcmc options. Up to us or our users.

Sounds like a good plan and the new Turing repo looks great! I'm especially curious about those Pluto notebooks, I haven't got around to trying them out yet.
Do you think you are happy with how things are looking at the moment? I'm slowly (very) working ony my code but if the approaches are so similar I'd be happy to contribute code here directly.

Well, there are a lot of really nice ideas in your work so I'm (i think) in the tail end of merging those ideas in the 2 mcmc versions.
Couple of the outstanding issues are:

Intro stuff and comparing with R should all move to Pluto notebooks and more interactive.
User should be able to run scripts from both repos in a single REPL session to compare results (e.g. quap() is a good example).
The src directory in StatisticalRethinking.jl v3.0.0 is still a mess. I'll clean that up later this month.
Relationship between precis and Particles (I think Richard also uses precis as a structure).
Only (important?) book figures will be stored in the plotsdir(). Others are either in Pluto notebooks or displayed live.

Still fine tuning all of that.
This weekend I'm hoping both mcmc versions are complete and reformatted up to chapter 3, including several notebooks.
You're welcome to contribute wherever you feel comfortable. Like precis() in Statisticalrethinking.jl. But I'm also fine to use my cycles to do that work and you look at chapters 6, 7 and 8.
Do you have a preference how I should refer to you, e.g. in authors, acknowledgements?


Remove Encrypted column from results

What does this PR do?
From version 8.0.14 and above of MySQL CE, an Encrypted column has been added: https://dev.mysql.com/doc/refman/8.0/en/show-binary-logs.html, we do not need it to compute the binary log stats. Without this update, the check would raise an Exception: ValueError: dictionary update sequence element #0 has length 3; 2 is required (the third element being that Encrypted column.
Motivation
Customer report
Review checklist (to be filled by reviewers)

[ ] PR title must be written as a CHANGELOG entry (see why)
[x] Files changes must correspond to the primary purpose of the PR as described in the title (small unrelated changes should have their own PR)
[x] PR must have changelog/ and integration/ labels attached
[ ] Feature or bugfix must have tests
[x] Git history must be clean
[ ] If PR adds a configuration option, it must be added to the configuration file.

This looks good to me, lets just add this to the tests CI so we are 👌

Actually, it looks like we use custom images for the CI. We've added something to the backlog to add this in the future, lets go ahead and merge for now. Thanks!

I am waiting for this fix, I hope I can review it before the my trial expired.


Weather App

Describe the project
A weather app that forcast current day and past 7 day weather.
User can check weather by city name and current location.
Issue Type:

[ ] Bug Report
[ ] Feature Request
[ ] Documentation
[x] New Project

hello @TusharKesarwani can i work on this issue???

Can you just give me brief about the issue. According to me I need to make weather app that that has the features that you requested in the issue.

hey @TusharKesarwani, can you just give me brief about the issue that what I need to do? According to me I need to make weather app that that has the features that you requested in the issue.

Yeah, you're right
Just implement the features

Thank you @TusharKesarwani ,I'll start working on it.

Hi @TusharKesarwani can i work on this project if its not assigned to anyone yet? i have already build the application on openweather api on nextjs with good ui.

Hi @TusharKesarwani can i work on this project if its not assigned to anyone yet? i have already build the application on openweather api on nextjs with good ui.
(https://nimbus-hub-weather.netlify.app/)
(https://github.com/kakashihatakesh6/nimbus-hub-weather)


build(linter): add new-react-perf rulegen task

Adds a new linter rule generation task, just new-react-perf-rule, for incorporating rules from eslint-plugin-react-perf into oxc.
Since this library has its own testing utilities and only 4 rules, I didn't bother writing code to port over test cases. If we deem this requisite I'll add this to the rulegen task.

Since this library has its own testing utilities and only 4 rules

lol


Evaluate use of KDE's map server

The KDE project generate and host their own map data in standard o5m file format at http://maps.kde.org/earth/vectorosm/v1/ -- no API key or anything like that, just plain HTTP open for anyone to grab.
If I understand it correctly, one big functional difference is that those files are square tiles and not split across region borders, so an index would be required which tiles correspond to which regions (although a benefit would be that online-only use wouldn't eat so much mobile data as it wouldn't require entire regions to be downloaded).
During pre-release development you could just use that server. Before Omaps hits app stores, asking the KDE people if they're OK with the amount of extra traffic. If not, a monthly sync to an Omaps server could possibly still make more sense than generating own maps files.

Looks like they aren't up-to-date currently...

Afaik, this data are used for KDE Itinerary and Marble. Especially, see this blog entry by @vkrause.
Of course, a featurewise connection of omaps with KDE Itinerary would be nice as well.

To clarify a bit what's on that server: what you see in the listing on http://maps.kde.org/earth/vectorosm/v1/ are only the static low-resolution tiles. Those are only updated occasionally and are based on NE rather than OSM. What you don't see directly there are the high-z tiles up to zoom level 17. Those are dynamically generated based on nightly updated OSM data and at level 17 are close to raw OSM data (no filtering or geometry simplification applied, only clipping to tiles), e.g. http://maps.kde.org/earth/vectorosm/v1/17/70403/42982.o5m. That's IMHO the real value this server provides. Whether that is something helping with your use-case I don't know though :)

I don’t see any value now for OMaps. We take the whole planet and generate all compressed maps. What is the use case to download raw data again from any server?


steps to expand logical volume

Seems very thorough and clear 🎉  I think this is ready for merge whenever y'all are happy with it.


⚠ ClamAV has degraded performance

In 6260754, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 195 ms

Resolved: ClamAV performance has improved in 62e2b11.


Remove ExternalDNS contour ingress workaround

This PR closes #589. It has been tested.
Component Tested

[x] metallb
[x] contour
[x] external-dns
[x] cert-manager
[x] dex
[x] gangway
[x] httpbin

@knrt10 Just one comment, we have a component httpbin for the same purpose you have deployed nginx.

@knrt10 just a small spell mistake in the commit message:
-Due to upstream issue in contour, address fiels was not setting on
-ingress resource. We introduces a workaround to solve that issue.
+Due to upstream issue in contour, address fields were not setting on
+ingress resource. We introduced a workaround to solve that issue.

@surajssd applied the httpbin component to. You can verify now curl dex.kautilya.dev.lokomotive-k8s.net

Removing cluster now

@ipochi updated. Please review

Updated

@invidian what tests do you suggest for this?

@invidian what tests do you suggest for this?

We should test, that the ingress host (either newly created one as part of testing or one from other component) resolves to the IP address in Ingress object.

@invidian can you please review

Thanks @invidian for reviewing. Updating the PR

e2e tests works fine.

@invidian can you please approve, stale review got removed on latest push to check CI

@knrt10 I pushed again last commit to trigger the CI one more time, as while doing some other tests I unpaused PacketARM pipeline, which is going to fail.

@invidian PacketARM did not get trigerred.


Could the classes like JsonApiDocument be public open and not package-private?

Problem
I'm currently working on an project where I'm implementing a generic API that serves as a gateway to a legacy software system. The API needs to expose resources in the JSON:API format. However, due to the nature of the project, I don't have the classes that describe the entities involved because the entities are unknown at the build-time and the definitions are loaded during runtime from a database.
Instead, I'd like to rely on the generic JSON:API models provided by the library, which are currently package-private.
Proposed Solution
I'd like to discuss the possibility of making the classes that represent JSON:API entities public within the library. This would be immensely helpful for projects like mine, where we need to work with JSON:API resources in a generic manner.
I'd appreciate feedback from the maintainers and the community on whether this proposed solution would be acceptable and what the implications might be. If there are concerns or alternative suggestions, please feel free to share your thoughts. Ultimately, I want to ensure that this change aligns with the goals and design principles of the library while addressing the specific needs of projects like mine.
Thank you for your time and consideration.

Hi Eduard, sorry for responding late. The current architecture is to use the generic HATOAS representation models when possible and the builder for JSON:API specific features. The class JsonApiDocument is an implementation detail that should not provide public API.
What is the concrete problem you have to solve, maybe there is another solution,

Hi Kai,
No worries, it was a PoC, so I tinkered with the necessary custom code, and it sufficed.
The problem I was solving was to generate a JSON:API resource from the data represented as Map<String, Object> (not a concrete class that I can provide annotations for). I reckoned that having a library that helps to build a valid JSON:API resource is better than generating everything from scratch. I like your library because of its simplicity, but it doesn't allow leveraging the low-level API it's based on.
I hope it's clearer now.

Ah, now I understand.
A possible solution for you problem would be to use the @JsonAnyGetter annotation. You could create a wrapper object for your map. Take a look at https://www.tutorialspoint.com/jackson_annotations/jackson_annotations_jsonanygetter.htm
If it does not work, let me know.


[Cosmos] clean up tests and add further configurations to testing matrix

Even though the SDK is now able to run consistently in the pipeline and causes no issues, we are missing further account configurations to be used in several tests that should be put in place to verify additional performance reliably. The Java SDK's setup files should be a good point for comparison.
There are also some tests that are currently disabled due to this - should look into getting those to work alongside this. Using this issue to track this work and to serve as a reminder.

Part 1: https://github.com/Azure/azure-sdk-for-python/pull/24198

Part 2: https://github.com/Azure/azure-sdk-for-python/pull/24215/files

This is done.


Once more unto Ghostscript mangling Tesseract-produced PDFs

To recap, when a Tesseract PDF (3.0x or 4.x) is run through Ghostscript the OCR layer will be mangled. Ghostscript's pdfwrite (gs -sDEVICE=pdfwrite -o out.pdf in.pdf) will display spaces between every character and get confused about word boundaries. Other PDF viewers tend to work but usually have problems with searching for text, because they read as the text as having spaces in between.
 Ghostscript <9.20 also corrupts any characters above U+00FF that happen to be present.)
There are lots of reasons someone might run a Tesseract PDF through Ghostscript pdfwrite: producing lower DPI renderings, PDF/A conversion, merging PDFs, changing paper sizes, sanitizing potential security holes like Javascript. There are also a lot of programs and services that use Ghostscript internally, sometimes without the user being aware of this. It's unfortunate that Tesseract PDFs don't play nicely with Ghostscript.
Ken Sharp (Ghostscript PDF dev) swears up and down that he can't do anything about it, essentially because Ghostscript interprets the input PDF into a page description language that is then rendered using pdfwrite. The output is visually identical, but otherwise the file is rewritten. Artifex also views preserving OCR text or other metadata as a bonus; if pdfwrite produces visually identical output they are satisfied.
See this comment from 2015:
https://bugs.ghostscript.com/show_bug.cgi?id=696116
Ken Sharp explains the essential difference is that the /DW (default glyph width) parameter on the GlyphLessFont is not understood by GhostPDL so it sets /DW 0 and manually positions each glyph (the -500).
[(T)-500(h)-500(e)-500]TJ

In English, Tesseract renders OCR with a font whose glyphs are 500 arbitrary units wide. Ghostscript reinterprets this as glyphs that are 0 units wide and moves the cursor 500 units between characters, and insists that it's the same thing.
I tried surgery on a pdfwrite-mangled file. I removed all of the -500 offsets, set to /DW 500 on the main font object, and removed the individual glyph width array /W [...] from the same. That works. (pdfwrite makes other minor changes to the PDF output too, but these don't matter as far as I know.) Writing a little script to fix mangled PDFs is possible, but it would be better to find a workaround.
So, is there any possibility of adjusting the glyphless font to work more like what Ghostscript expects so it survives the trip... without losing all of the other considerable and much appreciated effort that has gone into making glyphless work great with most other interpreters?
What are the commercial OCR tools doing to avoid similar issues?

As I think you know, Ken was already instrumental in our most recent invisible font iteration. Can you confirm that the problems you are seeing are true with HEAD (either the 3.0.5 or 4.x branch) as opposed to something older like 3.0.4? I want to make sure you are working with our the very latest compatibility tweaks to font metrics. Attaching an example document to this bug doesn't hurt.

Yes, I should have included an example, but it seems to affect just about everything.
Tesseract 4.00alpha (commit 2f10be5)
$ sha1sum tessdata/pdf.ttf
ac5300b169c99e90e9825dd8859b8a850edde22f  tessdata/pdf.ttf

Using testing/phototest.tif
$ tesseract --tessdata-dir . --oem 1  testing/phototest.tif _phototest pdf
Tesseract Open Source OCR Engine v4.00.00alpha with Leptonica
Page 1
$ pdftotext _phototest.pdf  -
This is a lot of 12 point text to test the
ocr code and see if it works on all types
of file format.
     All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Processing pages 1 through 1.

T h e

q u i c k

l a z y

f o x .

After Tesseract, before Ghostscript
_phototest.pdf
After Ghostscript
_phototest_gs.pdf
After Ghostscript, streams uncompressed with qpdf for easy viewing
_phototest_gs_uncompress.pdf
I also tried omitting --oem, not that we would expect this to make a difference. Tesseract 3.04.01 behavior is similar. I replicated this is in a Docker container with Tesseract 3.04.01 and Ghostscript 9.19.
Before Ghostscript, here is Acrobat XI showing that text search for words works normally.

After Ghostscript, here is Acrobat showing that a search for the word "p o i n t" matches because it is now convinced that there are spaces between each character. The highlighting is now misaligned as well.

Thanks, that is very clear. I'm always happy to tweak things on the Tesseract side to improve compatibility, but it does require careful testing. The tool of choice is ttx from fonttools which can transform the font pdf.ttf into an editable XML representation and back. I don't think we had anything missing with respect to font metrics, but you never know. Not sure when I might have time to play with this, but anyone is welcome to try. I'm somewhat hesitant to bother Ken more after all his contributions, but maybe that is just shyness.

Well, I tried fonttools for fun, and to my surprise I might have found a fix – with the important caveat that I have no idea what I'm doing.
--- pdf.ttx_original	2017-02-09 22:43:11.000000000 -0800
+++ pdf.ttx	2017-02-09 22:40:31.000000000 -0800
@@ -121,8 +121,8 @@
   </OS_2>

   <hmtx>
-    <mtx name=".notdef" width="0" lsb="0"/>
-    <mtx name=".null" width="0" lsb="0"/>
+    <mtx name=".notdef" width="1024" lsb="0"/>
+    <mtx name=".null" width="1024" lsb="0"/>
   </hmtx>

   <cmap>

I took Ken's remark that Ghostscript didn't like individual glyphs have a width of 0, so I gave them a width equal to full the glyph box. (1024 in .ttx units, 500 in PDF font units, from what I infer)
pdftotext works, search works, even macOS Preview works. Search in Chrome pdf.js seems to be broken however.

Chrome uses pdfium, Firefox uses pdf.js. Will take a closer look when I get a chance. Thanks for investigating.

Only the null character is used. Here's a control vs. experiment in for compatibility testing. I took a quick look at Acroread, Chrome, Firefox, evince on Linux and did not notice a difference. Need testing on all the other popular platforms (including the  mobile PDF viewers) to few comfortable. I'd also like to know exact what you did when you said "Search ... seems to be broken."
--- pdf.ttx.orig	2017-02-10 09:35:03.000000000 -0800
+++ pdf.ttx	2017-02-10 09:25:06.000000000 -0800
@@ -122,7 +122,7 @@

   <hmtx>
     <mtx name=".notdef" width="0" lsb="0"/>
-    <mtx name=".null" width="0" lsb="0"/>
+    <mtx name=".null" width="1024" lsb="0"/>
   </hmtx>

   <cmap>

control.pdf
experiment.pdf

on both pdfs pdf.js is broken:
image:
making use of the theory
copy & paste to gedit:
making
use
of
the
theory`

search:
`makinguseof  thetheory`

I'm trying to sort similar issues.  I am working with poppler, pdf2htmlEX (which uses poppler for extraction iirc), and Acrobat Pro 10.
I have been fighting exactly the same issues described here.
I see the exact same results with pdf.js that amitdo mentioned in the reply above on the following file...
asdf.pdf
This file started as a PDF from 300dpi scans, I extracted it to PNGs with Imagemagick, and OCR'd those with Tess v4 LTSM into a new PDF.
Here's a copy/paste of the first paragraph of the first page from OSX preview

take i atll back, and sure enough that's going to come but itwill take time. Firstofallletus ask a rather simple question. How can we be sure, how can we tell, whether any utterance is to be classed as a performative or not? Surely, we feel, we ought to be able to do that. And we should obviously very muchliketobeabletosaythatthereisagrammaticalcriterionforthis, some grammatical means ofdeciding whether an utterance isperformative. All the examples I have given hitherto do in fact have the same grammatical form;theyallofthem beginwith theverbinthefirstpersonsingularpresent indicative active-not just any kind of verb of course, but still they all are in fact of that form. Furthermore, with these verbs that I have used there is a typical asymmetry between the use of this person and tense of the verb and the use of the same verb in other persons and other tenses, and this asym- metry is rather an important clue.

and Acrobat Pro (also on OSX)...

take it all back, and sure enough that's going to come but it will take time.
First of all let us ask a rather simple question. How can we be sure, how can
we tell, whether any utterance is to be classed as a performative or not?
Surely, we feel, we ought to be able to do that. And we should obviously very
much like to be able to say that there is a grammatical criterion for this,
some grammatical means of deciding whether an utterance is performative.
All the examples I have given hitherto do in fact have the same grammatical
form; they all of them begin with the verb in the first person singular present
indicative active-not just any kind of verb of course, but still they all are in
fact of that form. Furthermore, with these verbs that I have used there is a
typical asymmetry between the use of this person and tense of the verb and
the use of the same verb in other persons and other tenses, and this asymmetry
is rather an important clue.

And pdf.js...

it
all
back,
and
sure
enough
that's
going
to
(ad infinitum, all words on a separate line)

Versions..
Preview 909.12
Firefox 51.0.1
Adobe Acrobat 10.1.3

@amitdo With the way this experiment is set up, finding that pdf.js gives the same result on control and experiment is not a regression. It just means there are more cases of text extraction not working perfectly unrelated to running them through Ghostscript. I confirmed that experiment.pdf, experiment_gs.pdf and control.pdf all have the problem you identified with "making use of the theory". Maybe there's something else we can do.
@RNCTX In this issue we're discussing how Ghostscript's pdfwrite utility seems to utterly ruin spacing in Tesseract-produced PDFs that previously appeared correctly in most viewers, rather than the general issue of spacing between characters not working in Tesseract PDFs. The real problem is the PDF spec itself:

Identifying Word Breaks
A document’s text stream defines not only the characters in a page’s text but also the words. Unlike a character, the notion of a word is not precisely defined but depends on the purpose for which the text is being processed. [...] applications all have their own ideas of what constitutes a word.

I read that with Windows 10 the default reader is the Edge browser. Someone should test it.

Checked Win10/Edge. Same thing, control_gs.psf fails and the others are
acceptable. Someone other than me should check things though.
On Sun, Feb 12, 2017 at 02:32 Amit D<EMAIL_ADDRESS>wrote:

I read that with Windows 10 the default reader is the Edge browser.
Someone should test it.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/tesseract-ocr/tesseract/issues/712#issuecomment-279209374,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABvcM8nWXMrLQOBIMd6SZiBjotpDRqpqks5rbt-kgaJpZM4L6dNS
.

@jbarlow83:  > In this issue we're discussing how Ghostscript's pdfwrite utility seems to utterly ruin spacing in Tesseract-produced PDFs that previously appeared correctly in most viewers, rather than the general issue of spacing between characters not working in Tesseract PDFs. The real problem is the PDF spec itself:
Yes, I understand the context, perhaps I should have clarified my post a bit better.  In working with the output in other tools, as you say in the OP, "ghostscript is used in many utilities, perhaps without even the knowledge that it is being used by the user."
In my case the PDF output of Tesseract is fine, in fact in terms of cleanliness as input for other tools it fares better than any other. But I cannot, for example, resize the output with without getting into ghostscript, as you accurately pointed out.
I am looking at your files in my various tools...
OSX Preview, pdf.js, and poppler output remain un-usable, but I agree that the others are improved.
Your change leaves us with Chrome and Acrobat working flawlessly, which is a pretty good start.
Chrome.txt
pdftotext.txt
pdf.js.txt
OSX Preview.txt
Acrobat X.txt

Can someone please test on iOS?

I can.  Will edit this in a few minutes.

Sorry for not being more clear. I need testing of control.pdf against experiment.pdf on iOS before we can submit the change.

Chrome_Control-Experiment_iOS.txt
Safari_Control-Experiment_iOS.txt
Firefox_Control-Experiment_iOS.txt
To clarify, these are from the PDF files in this post...
https://github.com/tesseract-ocr/tesseract/issues/712#issuecomment-279013509

Thank you very much. Okay, no known regressions, so let's get that revised font (pdf.ttf) in, snapshot the 3.0.5 branch, and ship to millions of users.

pdf.ttf.zip

Jeff,
Does this new ttf need to be added to both 3.05 and master branches?
ShreeDevi

भजन - कीर्तन - आरती @ http://bhajans.ramparivar.com
On Tue, Feb 14, 2017 at 12:07 AM, jbreiden<EMAIL_ADDRESS>wrote:

pdf.ttf.zip
https://github.com/tesseract-ocr/tesseract/files/772035/pdf.ttf.zip
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/tesseract-ocr/tesseract/issues/712#issuecomment-279481123,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AE2_o0O3YkyHAe9OMKsC_2n1nr9wovq4ks5rcKL1gaJpZM4L6dNS
.

@zdenop added it to the 3.05 branch, and I guess he will add it to 'master' soon...

done

Sorry to re-open, but it seems tesseract 4.0.0 shows the same behaviour:

Tesseract OCRs pdf (4.0.0)
use gs to reduce quality of images after ocr (latest version 28.11.2018)
Receive a s p a c e   a f t e r   e v e r y   l e t t e r

@WillemJansen Please open a new issue. Include your input, intermediate, and output files, the command lines you use to produce each, and note what PDF viewer you are using to extract text from the PDF.


Fixed numpy, scipy, matplotlib deprecation warnings

This PR removes some deprecation warnings issued during the tests.
I does not remove the deprecation warning for scipy.misc.ascent since the replacement (scipy.datasets.ascent) requires an extra dependency (pooch) which is not available in older Debian, but it makes the test code ready for the removal of scipy.misc.ascent.
closes #3734
closes #3715

Anything to be done with these ones:

Fixed one more use of scipy.ndimage.filters


Enable dashboard and alert lists reload with page refresh

With this change, dashboard and alert query calls can be trigger by refreshing the browser tab as well.

To test:

Open Argus in 2 separate browser tabs.
Create or delete dashboards in one of the tabs.
Refresh the other tab (command + r) and the dashboard list will be updated accordingly.

Current coverage is 36.46% (diff: 100%)

Merging #258 into develop will increase coverage by 0.01%

@@            develop       #258   diff @@
==========================================
  Files           260        260
  Lines         14214      14214
  Methods           0          0
  Messages          0          0
  Branches       2390       2390
==========================================
+ Hits           5181       5183     +2
+ Misses         8314       8312     -2
  Partials        719        719

Powered by Codecov. Last update af1299c...da7f01d


Unable to wrap DropdownItem inside another component

Hi and thanks for a great library! A lot of good looking and useful components in here!
In my use case I want to render a dropdown with the items coming being rendered inside another component but currently that's not possible. The Dropdown component crashes when clicked in such case.
Take a look at this code sandbox: https://codesandbox.io/s/angry-grass-mjjy51?file=/src/App.js where I have recreated a similar scenario.
I expected the Dropdown and DropdownItem components to use contexts to communicate with each other, but apparently that's not the case. Because if so this wouldn't be a problem I guess.
Is that something you think will be addressed? I really think it would be useful and it would also make it easier to solve the current accessibility issue with it, namely that you can't navigate the dropdown list using the keyboard as in a native dropdown.

hi @joakimbeng, thanks for the comment, that's a valid point. We also figured that contexts are probably more suited in this case. We'll refactor our select elements as soon as we have time. Also feel free to submit a PR if you like! :)


Missing TITLE in generated document

Gotenberg generates a document which starts with next information:
%PDF-1.4
%����
1 0 obj
<</Creator (Chromium)
/Producer (Skia/PDF m87)
/CreationDate (D:20210302164110+00'00')
/ModDate (D:20210302164110+00'00')>>
endobj
3 0 obj
<</ca 1
/BM /Normal>>
endobj
5 0 obj
<</Type /XObject
/Subtype /Image
/Width 400
/Height 103
/ColorSpace /DeviceRGB
/SMask 6 0 R
/BitsPerComponent 8
/Filter /FlateDecode
/Length 12568>> stream
......

as you can see there is no title
The title is added in the head in  HTML and it is shown in HTML, but it is not in PDF.
How can I add title to the document?

Related:

#207
#330